[LLVMdev] [RFC] OpenMP Representation in LLVM IR
greened at obbligato.org
greened at obbligato.org
Mon Oct 1 18:06:20 PDT 2012
Andrey Bokhanko <andreybokhanko at gmail.com> writes:
> Hi All,
> We'd like to make a proposal for OpenMP representation in LLVM IR.
I'm providing some brief comments after a skim of this..
> Our goal is to reach an agreement in the community on a simple,
> complete and extensible representation of OpenMP language constructs
> in LLVM IR.
I think this is a bad idea. OpenMP is not Low Level and I can't think
of a good reason to start putting OpenMP support in the IR. Cray has
complete functioning OpenMP stack that performs very well without any
LLVM IR support at all.
> As can be seen in the following sections, the IR extension we propose
> doesn’t involve explicit procedurization. Thus, we assume that
> function outlining should happen somewhere in the LLVM back-end, and
> usually this should be aligned with how chosen OpenMP runtime library
> works and what it expects. This is a deliberate decision on our part.
> We believe it provides the following benefits (when compared with
> designs involving procedurization done in a front-end):
This is a very high-level transformation. I don't think it belongs
in a low-level backend.
> 1) Function outlining doesn’t depend on source language; thus, it can
> be implemented once and used with any front-ends.
A higher-level IR would be more appropriate for this, either something
provided by Clang or another frontend or a some other mid-level IR.
> 2) Optimizations are usually restricted by a single function boundary.
> If procedurization is done in a front-end, this effectively kills any
> optimizations – as simple ones as loop invariant code motion. Refer to
> [Tian2005] for more information on why this is important for efficient
> optimization of OpenMP programs.
You're assuming all optimization is done by LLVM. That's not true in
> It should be stressed, though, that in order to preserve correct
> semantics of a user program, optimizations should be made thread-aware
> (which, to the best of our knowledge, is not the case with LLVM
Another reason not to do this in LLVM.
> We also included a set of requirements for front-ends and back-ends,
> which establish mutual expectations and is an important addition to
> the design.
This will increase coupling between the "front ends" and LLVM. That
would be very unfortunate. One of LLVM's great strength is its
I didn't look at the details of how you map OMP directives to LLVM IR.
I think this is really the wrong way to go.
More information about the llvm-dev