[LLVMdev] Design question on implementing OpenMP support

[Eric Christopher]

> The LLVM Polly wiki page earlier mentioned a design[2] where Clang and LLVM
> Polly would emit annotations to the code and there would be a seperate pass that
> would transform the code using these annotations. The issue I see with this
> approach is that this pass will have to be run immediately after the Clang and
> LLVM Polly emit these intrinsics. Otherwise a different pass might make the
> annotations invalid. A dead code elimination pass might remove the code for
> which these annotations were meant for example.
> 

It depends on how they're implemented of course, but if they were (for example)
metadata then yes something could delete it. If they were intrinsics then it could
also be deleted, but the optimizers would have to prove that they could be - which
means that the optimizers would need to be taught about whatever you're adding.

> I believe the simpler way is to have a library of classes to represent OpenMP
> directives and functions to transform these objects to LLVM objects and then
> have LLVM and Clang use this library directly.
> 
> I would like to know if I am missing something about the design using
> annotations as well as any alternative designs.

Well, "annotations" is pretty vague, though I can see Polly making the annotations
and then calling a Polly transform pass to transform before handing back to the
llvm optimizers. I think this is what was being talked about. This is more on the
line of autoparallelization rather than paying attention to OpenMP pragmas and
directives. For simple OpenMP pragma support it would probably be better to lower
to intrinsics and calls to an OpenMP library. This is what is currently done in
llvm-gcc (the calls and separation) - a similar mechanism could probably work for
clang. Ultimately I think the greater body of work is having clang parse and emit
the correct code rather than how to represent it in IR.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101109/3e40cf96/attachment.html>