[LLVMdev] [RFC] Parallelization metadata and intrinsics in LLVM (for OpenMP, etc.)

dag at cray.com dag at cray.com
Tue Oct 2 12:47:25 PDT 2012


Andrey Bokhanko <andreybokhanko at gmail.com> writes:

> There are three ways to make this work correctly:
>
> 1) Ignore OpenMP-related intrinsics and associated metadata. Least
> effort, least benefit (no OpenMP support). Yet, OpenMP programs
> compiled correctly, as if no pragmas are present -- including *exactly
> the same* number of routines and call graph (thanks to no
> procedurization in front-end). OpenMP specification allow such
> compilation. This might be the choice for targets that don't support
> OpenMP runtime library.

Actually, it is perfectly possible to have a program with OpenMP
directives that is NOT valid when those directives are ignored.  In
other words, it's possible to write a legal OMP program that relies on
parallelism to function correctly.  In practice this doesn't happen in
production codes but it's wrong to say the compiler can just ignore
directives with no problems whatsoever.

> 2) Make procedurization (including all runtime calls -- no intrinsics
> left after this step) at the very start of LLVM optimizer. No changes
> to optimizations, but no opportunity to optimize parallel code. As
> cheap and easy as one can do to support OpenMP. This might be a good
> choice for initial implementation.

This should work fine, but then why support intrinsics in LLVM at all.
I understand you're talking about an initial implementation.

> 3) Do some carefully chosen optimizations before procedurization. Do
> heavylifting (like loop restructuring optimizations) after
> procedurization. Some effort, a lot of benefit. This is essentially
> what is described in [Tian05] (referenced in our proposal).

What are the important optimizations?

> 4) Make all optimizations thread-aware. Best approach in theory, no
> compilers exist that go as far.

This is probably not practical.  It may be fine in academia but in
production environments the resources don't exist, unfortunately.

                          -David




More information about the llvm-dev mailing list