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