[LLVMdev] Parallel Loop Metadata

[David Tweed]

On Thu, Feb 7, 2013 at 6:55 PM, 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.
>
> Anyways, the fact that I do not know more of such passes to exist does not
> mean there isn't any. Especially when you consider there are out of tree
> passes in external projects that use LLVM. Therefore, the "safety first"
> approach of annotating the memory instructions and falling back to
> sequential
> semantics if non-annotated memory instructions are found sounds sensible
> to me.
>
>
Another possibility would be for passes to be only-just parallel metadata
aware, in that if a pass which doesn't know enough to correctly preserve
parallel metadata will not do anything if it sees any parallel markers
(maybe trying to find the smallest region to which this "don't run
yourself" applies, maybe not). In that way the metadata is guaranteed to
remain correct at the cost of missing out on some reorgranisations that are
done on non-parallel-metadata code. I don't know how well this would fit in
with the general philosophy of LLVM passes though.

(I'm also aware that we're coming at this from different directions: most
people are interested in auto-parallelisation, where missing a
parallelisation opportunity is just one of those unfortunate things, while
I have a personal interest in DSLs which try to present LLVM code with huge
"parallelise this" signs pointing at bits of it. It would be frustrating to
have carefully made sure the DSL twisted things into a parallelisable form
only to have parallelisation/vectorization "fall at the last hurdle".)

Cheers,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/cdd7f726/attachment.html>