Re: [Gomp-discuss] Somethings to think about ....

[Steven Bosscher]

Op ma 10-03-2003, om 15:39 schreef Biagio Lucini:
> We need to do two pretty orthogonal things, in my view:
> a) hack the middle end (your suggestion below may be appropriate)
> b) create the OpenMP library and all the framework (environment, locks
> etc.) needed to get them working in some code.

Add to this:
c) Hack the front ends to parse OpenMP pragmas.


> I am not very well prepared on (a). Besides, I think that the tree-ssa is
> still in evolution to bother it at this point with OpenMP directives. So
> we can postpone (a) for the moment or better do some work on the tree-ssa
> itself while waiting for an idea on how to use this framework for OpenMP.
> (by the way, I got the FSF signed copy of my copyright assignment form: in
> principle I *could* start to contribute patches to gcc...). Indeed 3 out
> of 6 of us are also and probably mainly tree-ssa contributors.

The way I see it, a) should indeed be postponed at least for a while. 
It would be nice to see stuff from the tree-ssa branch be merged to the
mainline before we start hacking it.  OTOH, GCC 3.4 is still in Stage 1,
GCC 3.3 isn't out yet and wont be for a while.  So the next "Stage 1",
for 3.5, could be as much as a whole year from now...

(c) can and should be done now.  Wasn't Seb working on something here??
For (b) we'll need to know more about how we should transform the AST to
transform the OpenMP tree_codes to OpenMP library calls.


> As for (b), I am ready if you are. I think that, while missing the
> compiler framework, a sensible thing to do is to assume that the threading
> model will be POSIX and to hard code it into the library functions.
> So building an OpenMP library that works when called from pthread code
> would be a substantial step in the right direction.

Hmm, I've tried to bring this up before but I don't recall we got any
conclusions from it. So...

How OpenMP-specific do we want to be?  Isn't there a more general name
we could use?  I don't like makeing everything very OpenMP-specific. 
IMO we should make the front end translate OpenMP pragmas to some
generic parallel tree codes.  There should be a generic library to
support concurrent execution.  The "OpenMP library" would just be a set
of wrappers that call into the generic concurrency support library.

The future may not be all OpenMP.  Having generic concurrency awareness
in the middle end may be useful for whatever may be beyond OpenMP.

Greetz
Steven