[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