[LLVMdev] Parallel Loop Metadata

Nadav Rotem nrotem at apple.com
Fri Feb 8 11:49:51 PST 2013


This is something that I can live with. Pekka, if you agree with this approach, can you write a formal proposal ?

Thanks,
Nadav

On Feb 8, 2013, at 10:20 AM, Tobias Grosser <tobias at grosser.es> wrote:

> 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 loop latch) and llvm.mem.parallel (attached to each memory
>>>>> instruction!).  I think that the motivation for the first metadata is clear -
>>>>> it says that the loop is data-parallel. I can also see us adding additional
>>>>> metadata such as llvm.loop.unrollcnt to allow the users to control the unroll
>>>>> count of loops using pragmas. That's fine. Pekka, can you think of
>>>>> transformations that may need invalidate or take this metadata into
>>>>> consideration ?
>>>> 
>>>> Any pass that introduces new non-parallel memory instructions to the loop,
>>>> because they think the loop is sequential and it's ok to do so. I do not know
>>>> any other such pass than the one pointed out earlier, reg2mem (if the
>>>> variables inside the loop body reuse stack slots). E.g., inlining
>>>> should be safe. So should be unrolling an inner loop inside a parallel loop.
>>>> 
>>> 
>>> I suggest that we only add the 'llvm.loop.parallel' metadata and not llvm.mem.parallem.
>> 
>> 
>> Ok.  A solution similar to Pekka's, using fewer annotations as you suggested, is
>> to reference in 'llvm.loop.parallel' all the datarefs to which the parallel
>> access semantics applies.  When the list of datarefs in 'llvm.loop.parallel'
>> differs from the datarefs in the loop, the annotation is deemed invalid.
> 
> That sounds elegant and seems to solve the correctness problems.
> 
> Cheers,
> Tobias





More information about the llvm-dev mailing list