search for: parallel_loop_access

It seems that at some point in the not-so-distant-past that the loop vectorizer gained the ability to vectorize loops without explicit `llvm.loop` & `llvm.mem.parallel_loop_access` metadata. While that's awesome, there seems to be a regression in that `llvm.mem.parallel_loop_access` metadata doesn't make it into the alias analysis, and therefore a `vector.memcheck` basic block is inserted, where as before it was not. It's unclear if this is a regression, as I as...

Adam, Please find the attached test case (run with ToT opt -O3). As you can see, `y_body` successfully is vectorized, though %33 and %46 are deemed MayAlias despite their exclusive use in loads ands stores marked with `llvm.mem.parallel_loop_access`. Many Thanks, Josh On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <anemet at apple.com> wrote: > > > On Mar 19, 2015, at 9:43 AM, Josh Klontz <josh.klontz at gmail.com> wrote: > > > > It seems that at some point in the not-so-distant-past that the loop > vector...

On 05/23/2013 06:52 PM, Redmond, Paul wrote: > I'm not even sure you would need the llvm.loop.parallel anymore since the > vectorizer could just look to see if the loop id on a parallel_loop_access > matches the loop id of the loop being vectorized. > > Does this make any sense? Yes. However, I think you still need use the self-referencing metadata trick or similar to make the metadata identifying a loop unique, though (to avoid merging it with the metadata nodes with the same data)...

Hi, I've been working on clang codegen for #pragma ivdep and creating the llvm.mem.parallel_loop_access metadata seems quite difficult. The main problem is that there are so many places where loads and stores are created and all of them need to be changed when emitting a parallel loop. Note that creating llvm.loop.parallel is not a problem. One option is to modify IRBuilder to enable attaching the m...

...o not fulfill the requirement of free ordering across iterations +are added to the loop. Therefore, this metadata is required, but not +sufficient, to consider the loop at hand a parallel loop. For a loop +to be parallel, all its memory accessing instructions need to be +marked with the ``llvm.mem.parallel_loop_access`` metadata that refer +to the same loop identifier metadata that identify the loop at hand. + +'``llvm.mem``' +^^^^^^^^^^^^^^^ + +Metadata types used to annotate memory accesses with information helpful +for optimizations are prefixed with ``llvm.mem``. + +'``llvm.mem.parallel_loop_acce...

Dear all, Here's an updated version of the parallel loop metadata patch. It includes documentation for the new metadata types with a semantics description. -- Pekka -------------- next part -------------- A non-text attachment was scrubbed... Name: parallel-loop-metadata.patch Type: text/x-patch Size: 12972 bytes Desc: not available URL:

....edu Dev" <llvmdev at cs.uiuc.edu> >> Sent: Thursday, February 28, 2013 1:30:57 PM >> Subject: [LLVMdev] parallel loop metadata simplification >> >> Hi, >> >> I've been working on clang codegen for #pragma ivdep and creating the >> llvm.mem.parallel_loop_access metadata seems quite difficult. The >> main problem is that there are so many places where loads and stores >> are created and all of them need to be changed when emitting a >> parallel loop. Note that creating llvm.loop.parallel is not a >> problem. >> >> One o...

...lly patch llvm to abuse it for other purposes... > I was recently thinking about how to extend the parallel loop metadata to support other hints. Does it make sense to use a single loop id metadata and attach hints to it? For example, here is a simple loop with llvm.loop.parallel and llvm.mem.parallel_loop_access metadata: loop.body: ; preds = %loop.body, %loop.body.lr.ph %indvars.iv = phi i64 [ %4, %loop.body.lr.ph ], [ %indvars.iv.next, %loop.body ] %__index.addr.07 = phi i32 [ %__low, %loop.body.lr.ph ], [ %7, %loop.body ] %ref1 = load i32*** %3, align 8, !ll...

On Wed, Jan 30, 2013 at 12:35 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Thank you all for comments, > > > On 01/30/2013 11:22 AM, David Tweed wrote: >> >> In a personal capacity I'm quite interested in the issues of producing >> from a >> high-level language some LLVM IR which is labelled with vectorization info >> (including

...raph 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 memory accessing instruction not marked with the metadata, the loop must be considered a sequential loop. This causes parallel loops to be converted to sequential loops due to optimization passes that are unaware of the parallel semantics and that insert new memor...

On 02/19/2013 05:51 PM, Hal Finkel wrote: > Understood. If you have some time, it seems that there are several sub-tasks: > > - Update the language reference Document the additional optional iteration id argument to llvm.mem.parallel_loop_access? I'll do this. > - Update the loop vectorizer (to update the metadata when it unrolls) > - Update the regular unroller I'll update the pocl's work-item replicator first (of which output is effectively the same as a fully unrolled parallel wiloop) to mark the iterations with...

...sday, February 28, 2013 1:30:57 PM >>>> Subject: [LLVMdev] parallel loop metadata simplification >>>> >>>> Hi, >>>> >>>> I've been working on clang codegen for #pragma ivdep and creating >>>> the >>>> llvm.mem.parallel_loop_access metadata seems quite difficult. The >>>> main problem is that there are so many places where loads and >>>> stores >>>> are created and all of them need to be changed when emitting a >>>> parallel loop. Note that creating llvm.loop.parallel is not a &...

...ment of free ordering across > iterations > +are added to the loop. Therefore, this metadata is required, but not > +sufficient, to consider the loop at hand a parallel loop. For a loop > +to be parallel, all its memory accessing instructions need to be > +marked with the ``llvm.mem.parallel_loop_access`` metadata that > refer > +to the same loop identifier metadata that identify the loop at hand. > + > +'``llvm.mem``' > +^^^^^^^^^^^^^^^ > + > +Metadata types used to annotate memory accesses with information > helpful > +for optimizations are prefixed with ``llvm...

...; >> Sent: Thursday, February 28, 2013 1:30:57 PM > >> Subject: [LLVMdev] parallel loop metadata simplification > >> > >> Hi, > >> > >> I've been working on clang codegen for #pragma ivdep and creating > >> the > >> llvm.mem.parallel_loop_access metadata seems quite difficult. The > >> main problem is that there are so many places where loads and > >> stores > >> are created and all of them need to be changed when emitting a > >> parallel loop. Note that creating llvm.loop.parallel is not a > >>...

...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 > inner loops to outer (parallel) loops. Then the outer > loop contains parallel_loop_access instructions referring to > the inner loop, making the outer loop non-trivially parallel. > > But these are probably rare cases as, at least in pocl, basic > optimizations have already been executed before the work-group > function generation where the parallel work-item loops are cr...

Hi Paul, On 02/28/2013 09:30 PM, Redmond, Paul wrote: > I'd like to reopen the discussion on requiring the > llvm.mem.parallel_loop_access metadata. I understand the reason for the > metadata is to protect against transformations that may introduce unsafe > parallel memory accesses (the reg2mem example.) I'm wondering if perhaps we > can make the metadata more user-friendly by providing a single loop metadata > which c...

...ific values (which are harder to lose). > I'm not saying we should annotate *all* memory instructions on a loop, > just the ones that make sense, or will help the vectorizer default to a > sane value. This is an interesting alternative! Do you mean that we would still add the llvm.mem.parallel_loop_access metadata, but only to such mem accesses that are assumed to be "hard or impossible to analyze" (to prove to be no alias cases)? Then we'd forget about the "parallel loop metadata" as is. Then we would rely on the regular loop carried dependency analyzer by default, but let...

On May 23, 2013, at 9:15 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 23 May 2013 14:52, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > I would like us to grow a few annotations, among others, one to force vectorization irrespective whether the loop vectorizer thinks it is beneficial or not - however, this is future music. > > Isn't that part

...Subject: [LLVMdev] parallel loop metadata simplification > >>>> > >>>> Hi, > >>>> > >>>> I've been working on clang codegen for #pragma ivdep and > >>>> creating > >>>> the > >>>> llvm.mem.parallel_loop_access metadata seems quite difficult. > >>>> The > >>>> main problem is that there are so many places where loads and > >>>> stores > >>>> are created and all of them need to be changed when emitting a > >>>> parallel loop. Note t...

...To: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, February 28, 2013 1:30:57 PM > Subject: [LLVMdev] parallel loop metadata simplification > > Hi, > > I've been working on clang codegen for #pragma ivdep and creating the > llvm.mem.parallel_loop_access metadata seems quite difficult. The > main problem is that there are so many places where loads and stores > are created and all of them need to be changed when emitting a > parallel loop. Note that creating llvm.loop.parallel is not a > problem. > > One option is to modify IRBui...