similar to: [LLVMdev] alias analysis during code generation

Pekka Jääskeläinen schrieb: > Is it somehow possible to use alias analyser data during code > generation, after instruction selection? I would need to run > the AA using MachineOperands, not Values. Is this in any way > in LLVM possible at the moment? i've been working on this (also because of a post-pass scheduler). i managed to hand the source values (values passed to the AA)

OK, I updated the text to LangRef in r209507 after some editing. On 05/11/2014 12:36 PM, Pekka Jääskeläinen wrote: > Hi, > > This looks good to me except that the first sentence > could already include "that refer to the same loop" or > similar. > > I could imagine that e.g. loop invariant code motion, > if applied to a parallel loop could hoist code out of >

Will do. I will write something up. Hal, your concern below isn't so much with the proposed semantics but rather with the use - that optimizations must respect the loop for which the metadata applies, correct? Thanks Jon -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, May 05, 2014 4:00 AM To: Tobias Grosser Cc: Pekka Jääskeläinen; Humphreys, Jonathan;

> > For the record, I just workarounded it in pocl by borrowing the > BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this should > be reconsidered. Yes, I agree. On 24 September 2012 15:08, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>wrote: > Well, > > To be honest I'm not very comfortable with the whole constant GEP > idea. It's a

I propose that we change the first paragraph of http://llvm.org/docs/LangRef.html#llvm-mem-parallel-loop-access-metadata: --- For a loop to be parallel, in addition to using the llvm.loop metadata to mark the loop latch branch instruction, also all of the memory accessing instructions in the loop body need to be marked with the llvm.mem.parallel_loop_access metadata. If there is at least one

Micah, Boaz, Do you guys have any ideas about how to fix this issue? Cheers, James On 24 September 2012 16:04, James Molloy <james at jamesmolloy.co.uk> wrote: > For the record, I just workarounded it in pocl by borrowing the >> BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this >> should >> be reconsidered. > > > Yes, I agree. > >

Hi, Sorry, With a prod from Silviu (cc'd) I now understand - I was interpreting your use of "constant GEP" as "GEP with constant operand" as opposed to "ConstantGEP node" which of course can only take a Constant* operand, not a Value* operand. I now fully see the problem and realise that my solution is also prone to that problem :) Cheers, James On 24

Hi Pekka, On Tue, Feb 26, 2013 at 11:08 AM, Pekka Jääskeläinen < pekka.jaaskelainen at tut.fi> wrote: > > > Isn't it possible that multiple nested loops share the header and > the pre-header in normalized loops? Thus, then adding metadata to the > preheader's branch would make the MD ambiguous for nested loops. > > The header can't be shared, otherwise

On 05/05/2014 10:14, Pekka Jääskeläinen wrote: > On 05/02/2014 07:22 PM, Humphreys, Jonathan wrote: >> Thanks for the link. I understand your concern of caution with metadata. >> I cannot, though, imagine how the dependence relation (independence) >> of two >> memory references can be affected by a third memory reference. If two >> references are independent

The documentation isn't clear about the uniqueness of loop identifier metadata. Should every loop have a unique loop id metadata? I think the answer is yes but I'm not sure how this can be enforced. A particular case I'm thinking of is something like: void foo() { for (...) { } } void bar() { for (...) { foo(); } } If the loops in foo and bar have the same loop id

Well, To be honest I'm not very comfortable with the whole constant GEP idea. It's a new thing to me and I do not fully understand its point in LLVM IR, so I probably wasn't very clear ;) Anyways, me bringing it up was meant as an example of what can happen if one (mis)uses the C function static variable semantics for something that really is a thread local variable (in usual thread

On Feb 7, 2013, at 10:55 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Hi Nadav, > > On 02/07/2013 07:46 PM, Nadav Rotem wrote: >> Pekka suggested that we add two kind of metadata: llvm.loop.parallel >> (attached to each loop latch) and llvm.mem.parallel (attached to each memory >> instruction!). I think that the motivation for the first

----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > Cc: "CVS Commit Messages for LLVM repository" <llvm-commits at cs.uiuc.edu>, "LLVM Developers Mailing List" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, January 29, 2013 3:27:03 PM

Hi Renato, On 01/28/2013 03:22 PM, Renato Golin wrote: > This seems an awfully specific check on a generic part of the code... If True. Perhaps the check is better encapsulated, e.g., in the Loop class? Or, if there's such thing as a loop-carried data dependency analyzer, the correct place could be there, as a trivial "no deps" analysis. > this metadata standard in any

----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, February 21, 2013 12:36:50 PM > Subject: Re: [LLVMdev] Parallel Loop Metadata > > The documentation isn't

On 01/29/2013 08:22 PM, Dan Gohman wrote: > "Ignore assumed dependencies" is shaky semantics. I haven't seen anything > explicitly spell out which dependencies a compiler is guaranteed to detect. > How can users use such a directive safely in a loop which has dependencies? > I understand that this is what icc's documentation says, but I'm wondering > if

Hi Pekka, I am okay with this patch, assuming that you follow the review of Tobias and Renato and provide a separate patch for the min-iter-count and a few test cases. I think that it would be a good idea to start a new thread and to discuss the best way to annotate loops in LLVM. Thanks, Nadav On Jan 28, 2013, at 5:49 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: >

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Tobias Grosser" <tobias at grosser.es>, "llvmdev at cs.uiuc.edu Dev" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, February 19, 2013

> > Okay. If you'll update your local BBVectorize patches, then we can pull them upstream. Then we'll just need to update the unroller. If I understand this thread correctly, you want to enable vecorization by telling the BB vectorizer that different operations are independent. I understand your motivation and I agree that this is indeed one way to do vectorization. However, I

On 01/28/2013 07:36 PM, Pekka Jääskeläinen wrote: > If there's a "yes" from the analyzer it still prevents the vectorization. > So, sort of a softened programmer-friendlier version of the semantics. That said, I cannot think of a case where it would *harm* if the dependency analyzer, if it can actually prove a dependency, serializes the code. Thus, the same metadata can be