[LLVMdev] [RFC] Progress towards OpenMP support

[Sanjoy Das]

Hi all,

I made some progress on implementing Hal's proposal [1] for
implementing OpenMP support in LLVM.  The patch I've attached just
barely compiles, but I'd like to get some input on the design early on
to prevent grief later.  I'd especially like some input on the
following points:

* Not dropping any metadata

I think it is better to have an analysis pass that provides a
consistent view of the current !parallel nodes.  By addRequired<> ing
it (called ParallizationMetadata currently) in the lowering pass and
only indirectly accessing the metadata through the analysis pass, we
can assure ourselves that we don't lower unsafe regions.

* No information is optional

It simplifies the implementation greatly if we assume that things like
task affinity etc. aren't optional.  I don't think this restriction
shifts any significant complexity to the frontends.

* Loops don't have lists of special handling regions

Since loops are always nested inside parallel regions, can't we
maintain this list in the parent region itself?

* Blurry line between asserting and silently ignoring

I'm not very clear on when it is "right" to silently drop metadata and
when to assert.  Right now I assert only when a !parallel MDNode has
an incorrect number of children (this is one thing simplified by
making all fields compulsory).  The verifier probably needs to know
about this constraint, something I haven't addressed yet.  Should our
assertions be stricter or must we not assert at all?


(The code is also up on Github [2]).

Thanks!

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052472.html
[2] https://github.com/sanjoy/llvm/tree/parallel-md


-- 
Sanjoy Das
http://playingwithpointers.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Create-a-class-structure-represent-the-various-kinds.patch
Type: application/octet-stream
Size: 25207 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120910/c0c3e063/attachment.obj>