similar to: [LLVMdev] parallel loop metadata question

OK, I updated the text to LangRef in r209507 after some editing. On 05/11/2014 12:36 PM, Pekka Jääskeläinen wrote: > Hi, > > This looks good to me except that the 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 >

I propose that we change the first paragraph 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

Thanks for the link. I understand your concern of caution with metadata. I cannot, though, imagine how the dependence relation (independence) of two memory references can be affected by a third memory reference. If two references are independent across loop iterations, then they are independent, and any other load or store cannot change that. Right? Jon -----Original Message----- From: Pekka

Will do. I will write something up. Hal, your concern below isn't so much with the proposed semantics but rather with the use - that optimizations must respect the loop for which the metadata applies, correct? Thanks Jon -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, May 05, 2014 4:00 AM To: Tobias Grosser Cc: Pekka Jääskeläinen; Humphreys, Jonathan;

On 02/08/2013 04:26 PM, Daniel Berlin wrote: > I'd love to see example cases where the pair analysis is the > difficulty, rather than the access analysis of any single memory piece > being the difficulty. I'm not completely sure what you mean, but is there really a difference between doing "pair analysis" across multiple iterations of the same instruction than doing it

On Fri, Feb 8, 2013 at 10:10 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > On 02/08/2013 04:26 PM, Daniel Berlin wrote: >> >> I'd love to see example cases where the pair analysis is the >> difficulty, rather than the access analysis of any single memory piece >> being the difficulty. > > > I'm not completely sure what you mean,

Hi Renato, On 02/08/2013 03:07 PM, Renato Golin wrote: > In this case, I'd prefer metadata on the variables that are assumed not > to alias, like the restrict keyword. > > It seems to me that having metadata on the loop basic blocks, since they > can be invalidated, will not help that much with the vectorizer more > than specific annotation on specific values (which are

On 05/05/2014 10:14, Pekka Jääskeläinen wrote: > On 05/02/2014 07:22 PM, Humphreys, Jonathan wrote: >> Thanks for the link. I understand your concern of caution with metadata. >> I cannot, though, imagine how the dependence relation (independence) >> of two >> memory references can be affected by a third memory reference. If two >> references are independent

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

On Fri, Feb 8, 2013 at 9:16 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Hi Renato, > > > On 02/08/2013 03:07 PM, Renato Golin wrote: >> >> In this case, I'd prefer metadata on the variables that are assumed not >> to alias, like the restrict keyword. > >> >> >> It seems to me that having metadata on the loop basic

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

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

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

On 02/08/2013 08:20 PM, Tobias Grosser wrote: > That sounds elegant and seems to solve the correctness problems. There is no big difference here except that the memory instructions would not need the metadata. I do not think the abundance of metadata is really the main problem, but what to do with passes that do not know about parallel loops. How to minimize the changes needed to make the

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

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

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

Hi, Here it is, just synched against the latest LLVM trunk. Shall I commit this now? 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 metadata (llvm.mem.parallel_loop_access) after optimizations that do not render the loop to a serial one. Some kind of helper function should be added to

On Feb 8, 2013, at 12:28 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > On 02/08/2013 08:20 PM, Tobias Grosser wrote: >> That sounds elegant and seems to solve the correctness problems. > > There is no big difference here except that the memory instructions > would not need the metadata. > > I do not think the abundance of metadata is really the

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