similar to: [LLVMdev] Parallel Loop Metadata

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 metadata is clear - > it says that the loop is data-parallel. I can also see us adding additional > metadata such as

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

Nadav Rotem wrote: > > 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 > >>

On 02/08/2013 07:02 PM, Sebastian Pop wrote: > Nadav Rotem wrote: >> >> 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

On 02/07/2013 11:49 PM, Nadav Rotem wrote: > > 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

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"

Now that we have a better understanding of the proposal for using per-instruction metadata, I think that we need to revisit the "single metedata" approach (Pekka's original suggestion). Reg2mem is indeed a problem, but the loop vectorizer can solve this in more than one way (detect or fix). The example pass that you mentioned below (the instrumentation pass), can be taught to

Hello all, Thanks for the comments. Attached is a new version with Tobias' and Sebastian's (final?) comments addressed. Any further comments are appreciated. Nadav suggested a request for comments in llvmdev before committing it. In order to describe the current idea of the parallel loop metadata, I think it's easiest to just copy-paste the documentation I wrote for this patch so

On Jan 29, 2013, at 12:51 AM, Tobias Grosser <tobias at grosser.es> wrote: > > # ignore assumed dependences. > for (i = 0; i < 4; i++) { > tmp1 = A[3i+1]; > tmp2 = A[3i+2]; > tmp3 = tmp1 + tmp2; > A[3i] = tmp3; > } > > Now I apply for whatever reason a partial reg2mem transformation. > > float tmp3[1]; > > # ignore assumed

On 02/11/2013 10:31 PM, Nadav Rotem wrote: > Now that we have a better understanding of the proposal for using per-instruction metadata, I think that we need to revisit the "single metedata" approach (Pekka's original suggestion). Following Andrew's comments we understood that Sebastian's proposal causes issues with inlining and unrolling. It seems we all agree that his

Hi Tobi, Thanks for reviewing the proposal. I imagine that it may also affects your parallelization work in Polly. > > I am not sure if I am able to follow your reasoning. How could the -loop-vectorizer detect parallelism violations? I had the feeling that we introduce the llvm.loop meta-data for the case where we want to inform the loop vectorizer that it can assume the absence of

> > 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 02/12/2013 11:59 PM, Nadav Rotem wrote: > LGTM. Please commit. Committed in r175060. Thanks all for the feedback. Yes, let's see what evolves as the best way to keep the metadata updated after "non-serializing optimizations". This metadata is produced by pocl for the "work-item loops" in the work group functions. Perhaps the #pragma ivdep support in Clang is going

On Feb 12, 2013, at 1:41 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Hi, > > Here it is, just synched against the latest LLVM trunk. Shall I commit this > now? LGTM. Please commit. > After committing, it could be worth some planning what is the best way to > provide an easy to use mechanism to "refresh" the parallel loop mem > access

On 01/28/2013 12:58 PM, Pekka Jääskeläinen wrote: > 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

On 02/18/2013 07:42 PM, Hal Finkel wrote: > Why don't we just add an optional iteration id to > !llvm.mem.parallel_loop_access? Sounds like a good idea to me. -- --Pekka

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

On 01/25/2013 04:21 PM, Hal Finkel wrote: > My point is that I specifically think that you should try it. I'm curious > to see how what you come up with might apply to other use cases as well. OK, attached is the first quick attempt towards this. I'm not proposing committing this, but would like to get comments to possibly move towards something committable. It simply looks for a

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:

On 02/08/2013 06:35 AM, Nadav Rotem wrote: > Hi Tobi, > > Thanks for reviewing the proposal. I imagine that it may also affects your parallelization work in Polly. Sure. I am interested in using it. >> I am not sure if I am able to follow your reasoning. How could the -loop-vectorizer detect parallelism violations? I had the feeling that we introduce the llvm.loop meta-data for