similar to: restrict pointer support in LLVM 4.0

Thanks. This is probably one of the patches. So let me rephrase my questions: 1- What is the status of work to support block-local restrict-qualified pointers. 2- Does the set of patches with “llvm.noalias” label, more or less cover this work? Thanks Ehsan From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of 陳韋任 via llvm-dev Sent: Thursday, June 01, 2017 7:57 AM

I probably misunderstood the question. You probably want to do this in SelectionDAG. On Fri, Oct 21, 2016 at 10:29 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > You can do this by changing instruction scheduling heuristics. I think the > more important question is if this correct always for all platforms. > > I don't know which scheduler you use. We use

On Thu, May 26, 2016 at 10:35 AM, Ehsan Amiri via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 7. Wildcard for prefixes - If some statements should be checked > regardless prefix, it should be used //{{*}}, //{{*}}-NEXT, //{{*}}-SAME > and etc. > >> 8. Prefix with regular expressions - If statement should be >> checked if prefix matches some regular

But then I should write // CHECK: something // SSE: something // SSE3: something With this feature it can be write // {{[A-Z0-9]+}} : something From: James Y Knight [mailto:jyknight at google.com] Sent: Thursday, May 26, 2016 5:53 PM To: Ehsan Amiri <ehsanamiri at gmail.com> Cc: Elena Lepilkina <Elena.Lepilkina at synopsys.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject:

7. Wildcard for prefixes - If some statements should be checked regardless prefix, it should be used //{{*}}, //{{*}}-NEXT, //{{*}}-SAME and etc. > 8. Prefix with regular expressions - If statement should be checked > if prefix matches some regular expression, it should be used {{regex}}:, > {{regex}}-NEXT and etc. > > > > I, too, think wildcard and regular

I overrode getInstrLatency and did some printing to see what is available there. It looks like the registers are still virtual at that point when getInstrLatency is called - is that correct? (we needed to make some decisions based on actual registers that have been assigned since some registers are reserved as address space pointers and we could vary the latency based on which address space

On Tue, Mar 22, 2016 at 1:41 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Sorry I should have been more clear (writing to many email in parallel) > > You're right. I was adding a +1 to you here. > > Especially I wrote "unless there is an acknowledgement that typeless > pointers won't be there before a couple of years" with the PassManager in >

I don't know enough about the tradeoff for 1, but 2 seems like a bandaid for something that is not a correctness issue neither a regression. I'm not sure it justifies "bandaid patches" while there is a clear path forward, i.e. typeless pointers, unless there is an acknowledgement that typeless pointers won't be there before a couple of years. -- Mehdi > On Mar 22, 2016,

I don't really mind, but the intermediate stage will not be very nice: that a lot of code / tests that needs to be written with bitcast, and all of that while they are deemed to disappear. The added value isn't clear to me considering the added work. I'm not sure it wouldn't add more work for all the cleanup required by the "typeless pointer", but I'm not sure

On Wed, Mar 16, 2016 at 11:00 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > David, > > Could you give us an update on the status of typeless pointer work? How > much work is left and when you think it might be ready? > It's a bit of an onion peel, really - since it will eventually involve generalizing/fixing every optimization that's currently leaning on typed

Back to the discussion on the RFC, I still see some advantage in following the proposed solution. I see two paths forward: 1- Change canonical form, possibly lower memcpy to non-integer load and store in InstCombine. Then teach the backends to convert that to integer load and store if that is more profitable. Notice that we are talking about loads that have no use other than store. So it is a

I feel very strongly that blocking work on making optimization bitcast-ignorant on the typeless pointer work would be a major mistake. Unless we expected the typeless pointer work to be concluded within the near term (say 3-6 months maximum), we should not block any development which would be accepted in the typeless pointer work wasn't planned. In my view, this is one of the largest

Hi Evan Thanks for the email. I had a look at gcc implementation of TBAA and I think three main steps in implementation of TBAA for LLVM will be this: April 20 ~ May 23: I will read gcc implementation in depth and play around with LLVM code. May 23 ~ July 6: Implementation and test of a simple version of TBAA that does not work with all aggregate types. I think part of the coding required for

But not what David was stating, unless I misread? I was specifically responding to David's wording: "If we're talking about making an optimization able to ignore the bitcast instructions - yes, that work is unnecessary & perhaps questionable given the typeless pointer work. Not outright off limits, but the same time might be better invested in moving typeless pointers

This is roughly what I wrote... > On Mar 22, 2016, at 1:31 PM, Philip Reames <listmail at philipreames.com> wrote: > > I feel very strongly that blocking work on making optimization bitcast-ignorant on the typeless pointer work would be a major mistake. Unless we expected the typeless pointer work to be concluded within the near term (say 3-6 months maximum), we should not block

I'd phrase this differently: being pointer-bitcast agnostic is a step towards support typeless pointers. :) We can either become bitcast agnostic all in one big change or incrementally. Personally, I'd prefer the later since it reduces the risk associated with enabling typeless pointers in the end. Philip On 03/22/2016 12:16 PM, Mehdi Amini via llvm-dev wrote: > I don't know

Dear all I am a PhD student of Computer Scince at Simon Fraser University ( http://www.cs.sfu.ca) interested in applying to GSoC. My PhD is focused on theoretical computer science, but since Sep. 2008 I have started working on Software projects again. Currently I am working in COSTAR lab ( http://costar.sfu.ca/) on a high performance regular expression engine based on Parallel bit streams

Hi Ehsan, In some cases modulo scheduling will insert copy instruction that end up as real copies in the final code. It unavoidable in some cases. For example, let's say a instruction defining a value is scheduled in the first iteration, but one of its uses is scheduled two iterations later. In this case, the kernel needs to create a copy because there will be two values live in the

Yes I use 2.6 as my OS seems to be too old for 2.7. Are there any restrictions on integer types for x86_64? On Tue, May 25, 2010 at 5:25 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 25, 2010, at 5:16 PM, Ehsan Amiri wrote: > > > Hello all > > > > I have a very simple handwritten .ll file that can be translated to > native assembly on

Hi Sjoerd We (at Huawei) also have a pass for this. Originally we implemented this back in 2018 and meant to upstream it, but there were some issues with the implementation that required some changes in the code. We started revising it,a few weeks ago. I thought now that there are multiple options, maybe we can discuss our approaches, and see if there is a preference in the community for one