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

[Johannes Doerfert via llvm-dev]

Dear community,

In preparation for the BoF on Parallel IR at the US developers meeting
we would like to collect feedback from the whole community. The
concerns, ideas, etc. will be summarized in the BoF and should provide a
good starting point for a discussion.

We know that over the years the topic of a parallel extension for LLVM
was discussed on the mailing list [0, 1, 2], workshops [3, 4] or in
scientific publications [5, 6, 7]. ***

We believe the solutions implemented in LLVM, namely parallel loop
metadata [8] and early proceduralization (aka. early outlining) for
OpenMP [9] or Cilk+ [10], are not well suited for optimization of "general
parallel codes". The reason are many fold and have been often
discussed alongside the various proposals mentioned above. Regarding
only the current implementation some problems have already manifested,
including
  - less optimization potential (partly) due to weak inter-procedural
    analysis [7, 11].
  - easy breakage of "parallelism" due to removal of metadata by
    intermediate passes [12, 13].
and others are likely to do so if we want to support more parallel
front-ends, optimizations and backends/runtimes.

In the beginning of this year a working group on
  "LLVM-HPC IR extensions for Parallelization, Vectorization and
   Offloading of LLVM compilers"
was initiated by Xinmin Tian. People from various companies, research
institutions and some universities discussed different approaches
regarding "parallelism" in the compiler IR/pipeline. Based on the
generally positive attitude regards a "more intrusive" parallel
extension we decided to resurrect the discussion once more, including a
BoF at the US developers meeting in 3 weeks.

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.

__Before__ we now dive into a technical discussion I would like people
to provide feedback on the proposed structure first. This will
(hopefully) allow a more organized and constructive discussion.


Thanks,
  Johannes, Simon and Kevin



*** All lists of references are incomplete. They provide a starting
    point for interested readers but not a summary of what happened.


[0]  http://lists.llvm.org/pipermail/llvm-dev/2015-February/082220.html
[1]  http://lists.llvm.org/pipermail/llvm-dev/2015-March/083134.html
[2]  https://groups.google.com/forum/#!topic/llvm-dev/n-ia9kJyg6w
[3]  https://llvm-hpc2-workshop.github.io/talks.html#khaldi
[4]  https://www.hipeac.net/events/activities/5848/compiler-intermediate-representations/
[5]  http://dl.acm.org/citation.cfm?id=2523721.2523727
[6]  http://dl.acm.org/citation.cfm?id=2095103
[7]  http://cpc2016.infor.uva.es/wp-content/uploads/2016/06/CPC2016_paper_12.pdf
[8]  http://llvm.org/docs/LangRef.html#llvm-mem-parallel-loop-access-metadata
[9]  http://llvm.org/devmtg/2014-10/Slides/Bataev-OpenMP.pdf
[10] http://cilkplus.github.io/
[11] http://openmp.org/sc13/OpenMPBoF_LLVM.pdf
[12] https://reviews.llvm.org/D5344
[13] https://reviews.llvm.org/D12710

-- 

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161014/104caa58/attachment.sig>