[LLVMdev] LLVM Parallel IR

Renato Golin renato.golin at linaro.org
Wed Mar 11 09:30:48 PDT 2015

On 10 March 2015 at 08:36, Kevin Streit <streit at mailbox.org> wrote:
> Again, optimizations could break it, violating a possible contract with the user.

AFAIK, all these annotations are more hints than contracts. Adding
#pragma omp simd on a loop that has forward dependencies that cannot
be solved should not make the loop vectorize (incorrectly). Same goes
for standard OMP, threads and other types of parallel computation.

> The headaches that this approach causes me are that basic analyses like
> dominance, reachability and the like are broken

Yes, intrinsics are heavy handed and will stop the compiler from being
smart in many ways.

> One possibility to do this gradually might also be to have a seperate, parallel, IR, say PIR, that will be
> lowered to regular IR at some point (however this point is chosen).

So, we have Polly that does that, and it's not a trivial issue. Adding
yet another representation is worrying. The IR Language Reference is
comprehensive and authoritative, and is a great resource for building
IR from ASTs or adding optimisations. For every new representation, we
have to add a similar document, plus another to tell how that is
represented in other IRs, so that transformations are well defined. I
don't think we have that for Polly, and adding PIR would double that

I'd be much more open to slow moving changes to the current IR
(especially if they benefit Polly, too). This path worked very well
for exception handling (which is an equally complex case), and should
work for parallelism.

But that's just my opinion. :)


More information about the llvm-dev mailing list