similar to: [LLVMdev] [PATCH] parallel loop metadata

Hi Pekka, On 2013-01-29, at 2:42 PM, Pekka Jääskeläinen wrote: > Maybe the safe thing here is to rename it back to the honest > "llvm.loop.parallel" or similar and we can add a separate one for > the assumed_dep later on. This one would support the truly parallel > loops (at least OpenMP for and OpenCL WIloops) where no compiler > checking at all can be assumed by the

----- 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

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Dan Gohman" <dan433584 at gmail.com> > 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 1:42:27 PM >

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

On 01/25/2013 04:00 PM, Hal Finkel wrote: > Based on this experience, can you propose some metadata that would allow > this to happen (so that the LoopVectorizer would be generally useful for > POCL)? I suspect this same metadata might be useful in other contexts (such > as implementing iteration-independence pragmas). I cannot yet. In this hack I simply changed LoopVectorizer to

> I am in favor of adding metadata to control different aspects of > vectorization, mainly for supporting user-level pargmas [1] but also for > DSLs. Before we start adding metadata to the IR we need to define the > semantics of the tags. "Parallel_for" is too general. We also want to control > vectorization factor, unroll factor, cost model, etc. These are used to

On 01/29/2013 10:17 PM, Hal Finkel wrote: > Will parallel always be synonymous with no_interiteration_dependencies? I'm > sightly worried that 'parallel' seems too much like a directive, and we may > want it to mean something else in the future. I think the semantics of a "parallel loop" is: If my loop, I hereby state as "parallel", has loop-carried

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Nadav Rotem" <nrotem at apple.com> > Sent: Friday, January 25, 2013 8:14:57 AM > Subject: Re: [LLVMdev] LoopVectorizer in OpenCL

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

Pekka, I am in favor of adding metadata to control different aspects of vectorization, mainly for supporting user-level pargmas [1] but also for DSLs. Before we start adding metadata to the IR we need to define the semantics of the tags. "Parallel_for" is too general. We also want to control vectorization factor, unroll factor, cost model, etc. Doug Gregor suggested to add the

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"

----- 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/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

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Paul Redmond" <paul.redmond at intel.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Tobias Grosser" <tobias at grosser.es>, "<llvmdev at cs.uiuc.edu>" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, March 5,

Hi Ralf, On 01/31/2013 05:44 PM, Ralf Karrenberg wrote: > As for the current status, the loop vectorizer is only able to vectorize > inner loops and (I think) does not handle function calls and memory > operations well. This will prevent it from vectorizing a large group of > OpenCL kernels, and certainly all "interesting", more complex ones. Agreed -- but not being able to

I've attached some IR which shows what I'm asking about. If you run this through opt "inner" will be inlined and both loops in "outer" will have the same loop id metadata.. paul On 2013-02-21, at 2:07 PM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Paul Redmond" <paul.redmond at intel.com> >> To: "Pekka

Hello, I am trying to vectorize the following loop but the vectorizer says: "Found a possible write-write reorder" and does not vectorize. Why? for (j=0; j < 8; j++) { jj = j << 3; m2[j][0] = diff[jj ] + diff[jj+4]; m2[j][1] = diff[jj+1] + diff[jj+5]; m2[j][2] = diff[jj+2] + diff[jj+6]; m2[j][3] = diff[jj+3] + diff[jj+7]; m2[j][4] = diff[jj ] -

On 01/25/2013 09:56 AM, Nadav Rotem wrote: > Thanks for checking the Loop Vectorizer, I am interested in hearing your > feedback. The Loop Vectorizer does not fit here. OpenCL vectorization is > completely different because the language itself is data-parallel. You > don't need all of the legality checks that the loop vectorizer has. I'm aware of this and it was my point in

Hi, On 2013-03-03, at 2:58 PM, Hal Finkel wrote: > > I agree; we should only annotate accesses that some from language-level array/pointer(/reference) accesses. We should then rely on other passes to clean up (or not) the remainder. > > I think that the best way to handle local arrays is to issue a warning when they occur inside an annotated loop that the local array will probably

On 03/05/2013 07:12 PM, Redmond, Paul wrote: > Attached is my most recent patch for clang. Maybe someone wants to play with > it or has ideas on how to refine the llvm.mem metadata generation. + } else if (I->mayReadOrWriteMemory()) + I->setMetadata("llvm.mem.parallel_loop_access", + L.GetLoopID(I->getContext())); + } Here we want to not add