Hi all,
I’m a grad student from MIT and as part of my thesis, I will be propagating parallelism in the IR level. I will be modifying clang and adding LLVM IR metadata annotations to indicate parallel regions and loops, then write optimizer passes that will run on top of the annotated LLVM IR.
There has been a lot of research lately on Parallel IRs, such as SPIR[1], SPIRE[2] and INSPIRE[3] lately, so I will be starting off from there in order to design a good parallel representation. With this patch a lot of the modern parallel C interfaces (pthreads, cilk, openMP etc.) will be translated to one unified LLVM IR.
My goal is to make this part of the LLVM mainstream branch eventually. I’d really like to discuss design considerations that you might have, or any objections or pointers (pun intended). It is also possible somebody is already working on this. If so, we might be able to help each other. Looking forward to discussing this with all you.
Cheers,
Lef
Lefteris Ioannidis,
Massachusetts Institute of Technology '14
Department of Electrical Engineering and Computer Science,
elefthei@mit.edu | http://web.umit.edu/elefthei/www/
Hi Lef,
my name is Herbert and I'm the designer of INSPIRE.
With INSPIRE we could establish a unified model for all kind of parallel interfaces, similar to the objectives you are targeting with your work. Yet, our IR is based on a high-level IR for various other reasons. Nevertheless, I guess the general parallel concepts should be adaptable to LLVM as well.
In addition to the paper you cited, our IR constructs and in particular its parallel primitives are covered in fare more detail by this thesis [1<http://www.dps.uibk.ac.at/~csaf7445/pub/phd_thesis_jordan.pdf>\].
In case you have any questions, or you'd like to discuss design decisions we made for our IR, I'm glad to provide answers and/or contributions to upcoming discussions.
Cheers,
Herbert
Hi Lef,
Your project sounds interesting, and please keep in touch regarding your progress. There are a few things to keep in mind, the most important is that if you use metadata to carry your annotations, then it must be legal for an optimization pass to drop your metadata without rendering the output invalid/miscompiled. The fact that metadata can be dropped is one of the major impediments to using that facility to implement OpenMP lowering in LLVM. Another possibility, not mutually exclusive with using metadata, is to use intrinsics. You can mark intrinsics as having unmodeled side effects, which will prevent them from being dropped. Unfortunately, doing so will also interfere with many optimizations. You might introduce some other class of semantics for them, but then there are other considerations: How difficult will it be to integrate into the existing infrastructure. What transformation and/or analysis passes need to be taught about the new feature for correctness, and how many to provide reasonable performance? Is this auditing easy or hard? Will it be easy to figure out, when writing new IR transformations, what can be legally done with the new metadata/intrinsics/etc.?
I highly recommend that you discuss any potential design on this list with those of us who are interested; there are many potential pitfalls, and we can likely help to you avoid at least some of them.
-Hal
The key design considerations would be:
1. Correctly represent parallel semantics
2. Minimize (or no) side-effects on scalar optimizations so the thread-code generated can be optimal with scalar and parallel execution.
3. Does not require changes (or just require very minimal changes) in existing LLVM optimizations while maintaining the correct semantics for both scalar and parallel semantics.
Xinmin