search for: ignore_assumed_deps

On 01/28/2013 09:23 PM, Redmond, Paul wrote: > If ivdep are the semantics you're going for I'd use that. Fine, except I prefer not to include 'v' in it. Vectorization is merely a one way to parallelize the loop. How does llvm.loop.ignore_assumed_deps sound? -- --Pekka

...function calls it inlines to the parallel loop body. These features can be added later on in an incremental fashion. I added cc to llvmdev as this might be worth wider attention. On 01/29/2013 07:29 PM, Nadav Rotem wrote: > Hi Pekka, > > I am okay with the first part (of adding lvm.loop.ignore_assumed_deps), but I am not sure why we need the second one. > > Adding metadata to every single (memory) instructions sounds fragile to me, and I am not sure that I understand the motivation. > > Thanks, > Nadav > > On Jan 29, 2013, at 8:38 AM, Pekka Jääskeläinen<pekka.jaaskelainen at t...

...set of memory accesses does not have dependences within the mentioned loop". Like this, the introduction of additional memory accesses which may very well introduce dependences that we need to preserve, can be easily detected. The parallelism check would now be: "In case the llvm.loop.ignore_assumed_deps meta-data is found in a loop header _and_ all memory accesses in the loop are referenced by this meta-data, the loop is parallel. If there is a memory access that does not reference the ignore_assumed_deps meta-data, we can not assume anything about the loop. Cheers, Tobias

Hi, Attached is a patch which uses a simple "parallel_loop" metadata attached to the loop branch instruction in the loop latch for skipping cross-iteration memory dependency checking in the LoopVectorizer. This was briefly discussed in the email thread "LoopVectorizer in OpenCL C work group autovectorization". It also converts the "min iteration count to vectorize"

...ry accesses does not have dependences within the mentioned > loop". Like this, the introduction of additional memory accesses which may very > well introduce dependences that we need to preserve, can be easily detected. The > parallelism check would now be: "In case the llvm.loop.ignore_assumed_deps > meta-data is found in a loop header _and_ all memory accesses in the loop are > referenced by this meta-data, the loop is parallel. If there is a memory > access that does not reference the ignore_assumed_deps meta-data, we > can not assume anything about the loop. Sounds reasonable,...

On 01/28/2013 06:45 PM, Nadav Rotem wrote: > 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. OK. Any opinions on the location of the isParallelLoop() check? Shall I put it to Loop so it is more widely accessible? I.e. Loop->isParallel(). -- Pekka

It sounds like a good idea to move the method in to Loop. Is there a naming scheme for metadata? I think llvm.loop.* would be helpful for loop-specific metadata. As for parallel I think it is a little too generic. If ivdep are the semantics you're going for I'd use that. paul On 2013-01-28, at 12:03 PM, Pekka Jääskeläinen wrote: > On 01/28/2013 06:45 PM, Nadav Rotem wrote: >>

...s back to) is a legal execution ordering of a fully parallel loop. As soon as someone points out what is the true difference (basically the set of guaranteed analysis done by the compiler) between "ivdep" and "parallel" then we can add a new metadata type, e.g., the llvm.loop.ignore_assumed_deps to support that. Anyways, my desire is to start from something as it's easier to build on existing foundations. > To clarify history, the reason that the metadata-based OpenMP schemes died > was not due to the "propeller" arguments (which said that parallelization > semantic...

...ion ordering of a fully parallel loop. > > As soon as someone points out what is the true difference (basically > the set of guaranteed analysis done by the compiler) between "ivdep" > and > "parallel" then we can add a new metadata type, e.g., the > llvm.loop.ignore_assumed_deps to support that. Anyways, my desire is > to start > from something as it's easier to build on existing foundations. As various people have expressed, "the set of guaranteed analysis done by the compiler" is the null set, and so this should suffice for these pragmas as well. Nev...