llvm dev - Nov 2010 - [LLVMdev] Design question on implementing OpenMP support

Hello,

I had earlier mailed the list[1] about adding OpenMP support to Clang and LLVM
Polly.

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.

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.

[1] http://128.174.252.7/pipermail/llvmdev/2010-October/035568.html
[2]
http://wiki.llvm.org/index.php?title=Polyhedral_optimization_framework&oldid=991

--
Gautam

> 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>