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 inhibit vectorization (I say probably because SROA, etc. may make it go away). We can think about implementing privatization transformations in the future. Even this warning can be a follow-up enhancement. > > -Hal >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. paul -------------- next part -------------- A non-text attachment was scrubbed... Name: ivdep.diff Type: application/octet-stream Size: 23634 bytes Desc: ivdep.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130305/c30cc2fc/attachment.obj>
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 metadata to load/store instructions which originate from unsafe allocas like discussed. I wonder if there's an easier way to find this out than to follow the pointer argument until a global or a function argument is found? Maybe that can be done via a helper method which can be later augmented with more "safe cases"? -- --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, 2013 11:49:28 AM > Subject: Re: [LLVMdev] parallel loop metadata simplification > > 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 metadata to load/store > instructions which originate from unsafe allocas > like discussed. > > I wonder if there's an easier way to find this out than to follow > the pointer argument until a global or a function argument is found? > Maybe that can be done via a helper method which can be later > augmented > with more "safe cases"?If we're discussing a Clang patch, this discussion should be moved to the cfe-commits list. -Hal> > -- > --Pekka >