[llvm-dev] Parallel IR [PIR] --- BoF preparation discussion

[Francesco Petrogalli via llvm-dev]

On 15/10/2016 10:22, "llvm-dev on behalf of Johannes Doerfert via
llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of
llvm-dev at lists.llvm.org> wrote:

>Hi Renato,
>
>On 10/14, Renato Golin wrote:
>> On 14 October 2016 at 10:38, Johannes Doerfert via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > To structure the mailing list discussion we propose to:
>> >   - Inform a broader audience on the (currently) proposed approaches
>> >     targeted specifically at LLVM (including but not necessarily
>>limited
>> >     to the work by Intel, Dounia Khaldi et al, Tao Schardl et al and
>>our
>> >     own work)
>> >   - Collect/summarize arguments for and against a "more intrusive"
>> >     parallel representation in LLVM.
>> >   - Collect/summarize requirements including abstract design goals but
>> >     also concrete examples that should (not) be supported.
>> >
>> > => We will use the summaries to prepare a short presentation for the
>>BoF
>> >    (~10min) which allows us to use the majority of time for a
>>qualified
>> >    discussion on the topic.
>> 
>> Hi Johannes,
>> 
>> I think this is a great idea! With a deadline to meet (~2 weeks), and
>> a particular focus (feed the BoF discussion), I think we can keep
>> ourselves on track.
>I hope so yes.
>
>> I particularly welcome a more intrusive change to IR (away from
>> metadata) to hold parallelism ideas, since we're past the point where
>> SIMD / multi-core was considered only an optimisation, and the
>> compiler IR has to evolve to match.
>I fully agree and more and more people seem to do the same.
>
>> But I'm also worried that we'll end up lost in the multitude of ways
>> we can extend the IR. A step by step pragmatic approach is fundamental
>> to keep it sane and robust, and I think your starting point conveys
>> that well.
>I agree. Defining and understanding the scope of the proposed or just
>desired extensions is hard but necessary. More on this below.
>
>> We need to make sure we cover simpler cases first, without losing
>> sight of the more complicated cases as an evolution of whatever plan
>> we come up with. But also, we need to be backward compatible, so that
>> the optimisation passes don't start depending solely on the new IR
>> constructs to work.
>I guess backwards compatibility with the existing OpenMP/Cilk frontends
>is not too hard. Early proceduralization should always work.
>
>Regarding the simple cases and more complicated ones I will put examples
>in a google doc to show how easy parallel constructs can become hard to
>represent (e.g., due to control flow or non-wait annotations). So far we
>mostly looked at how to model the parallelization schemes of OpenMP,
>Cilk and OpenCL but also defined some we do not want to represent at all
>(e.g., general task/thread) parallelism). I think examples will help to
>argue about cases in a more constructive (or better target oriented) way.

Hi Johannes,

Great idea! I just want to add a pointer to some of the work (I am aware
of) that has beed done in defining an IR that can represent parallelism,
called “INSPIRE".

Quoting the relevant parts in the abstract of the paper that describe this
IR:

   “ […] INSPIRE, a unified, parallel, high-level intermediate
representation.
Instead of mapping parallel constructs and APIs to external routines,
their behaviour is modeled explicitly using a unified and fixed set of
parallel language constructs. Making the parallel control flow
accessible to the compiler lays the foundation for the development of
reusable, static and dynamic analyses and transformations bridging the
gap between a variety of parallel paradigms “

The paper can be found here:
http://dl.acm.org/citation.cfm?id=2523721.2523727

I don’t know how much of this can/should be reused in defining the new
parallel IR, but it might be a good starting point.

I am looking forward to see the outcome of this new development in LLVM!

Regards,

Francesco

>
>Cheers,
>  Johannes
>
>-- 
>
>Johannes Doerfert
>Researcher / PhD Student
>
>Compiler Design Lab (Prof. Hack)
>Saarland Informatics Campus, Germany
>Building E1.3, Room 4.31
>
>Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
>Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert