Re: [Gomp-discuss] Open64's implementation of OpenMP

[Steven Bosscher]

Op di 04-02-2003, om 19:26 schreef Pop Sébastian:
> Having a sub-branch for the beginning will be of great help.  
> I think we'll have to merge it quickly to tree-ssa once we begin to touch 
> the middle-end bits.  That could go very quickly if we decide to use a 
> representation as in Open64: a single tree node (for example OMP_PRAGMA)

I really don't like the idea of making this whole thing too
OMP-specific.  OpenMP may not be around for ever, but concurrency
probably will be around for a while. Also, the whole infrastructure in
the middle end that we're talking about now has the potential to be much
bigger than OpenMP itself (autoparallelization? MPI-code? Who knows...)

I would prefer some generic names like FOR_EACH (or PARALLEL_FOR, or
FORALL, DOALL, whatever), BARIER, SECTION, etc.  OK the names I just
typed down are still very OpenMP, but I guess you get the idea: Have
tree nodes that express explicit concurrency and translate OpenMP to
those tree nodes.

IMO the goal should be to come up with a minimal representation in tree
nodes of the OpenMP semantics.  That's why I'm so interested in what
Scott has learned from comparing the Fortran and C/C++ specs.

> with some information attached to it (pragma type, and pragma arguments).
> for all pragmas that are not yet lowered.  Translation of these
> OMP_PRAGMA to RTL will emit a warning (something like: 
> "Pragma %s not handled.".  

I think it's wrong to propagate pragma's that deep into the middle end.
#pragma is C/C++, the middle end should be language independent. 
Warnings about unhandled #pragmas should go in the front end(s).
 
> Once we have all this I think we could merge with tree-ssa, allowing 
> analyzers to emit nodes with parallel semantics based either on the
> OMP_PRAGMA nodes, or on their results.

Why not make the parser generate an explicitly concurrent AST, and make
the middle-end ignore them until they're actually implemented?

Greetz
Steven