search for: iteration_id_integer

Displaying 4 results from an estimated 4 matches for "iteration_id_integer".

2013 Feb 18
2
[LLVMdev] Pointer Context Metadata (was: Parallel Loop Metadata)
...quot; to the memory accesses. In this case it would communicate that the mem access belongs (or belonged, if fully unrolled) to a loop and it can alias only with the accesses from the same iteration, or with accesses without the metadata. Something like: llvm.mem.parallel_loop_iteration [loopid] [iteration_id_integer] This can help the "pairing" of the BBVectorizer: it can try to pair with the different iterations first. The ParallelLoopIterationAA can look at this metadata and if the other instruction has also a parallel_loop_iteration MD that points to the same loopid (the self-referencing id metad...
2013 Feb 18
0
[LLVMdev] Pointer Context Metadata (was: Parallel Loop Metadata)
...would communicate that the mem > access > belongs (or belonged, if fully unrolled) to a loop and it can alias > only with > the accesses from the same iteration, or with accesses without the > metadata. > > Something like: > > llvm.mem.parallel_loop_iteration [loopid] [iteration_id_integer] Why don't we just add an optional iteration id to !llvm.mem.parallel_loop_access? > > This can help the "pairing" of the BBVectorizer: it can try to pair > with > the different iterations first. This makes sense. > The ParallelLoopIterationAA can look > at this...
2013 Feb 17
0
[LLVMdev] Parallel Loop Metadata
----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Tobias Grosser" <tobias at grosser.es> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Sunday, February 17, 2013 2:32:25 PM > Subject: Re: [LLVMdev] Parallel Loop Metadata > > > > > > On Feb 11, 2013, at 2:58 PM,
2013 Feb 17
3
[LLVMdev] Parallel Loop Metadata
On Feb 11, 2013, at 2:58 PM, Tobias Grosser <tobias at grosser.es> wrote: > 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