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

[Biagio Lucini]

On Mon, 10 Mar 2003, Steven Bosscher wrote:

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

[...]

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

I sort of agree. I agree that it must be postponed, and the best thing
would be to start to do it when the tree-ssa will be in the main branch.
However I hope this would be sooner than in 1 year time :-)

>
> (c) can and should be done now.  Wasn't Seb working on something here??

Yes, as far as I remember he had some ideas to try with the pragmas.

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

Couldn't you start with just some threaded C code? In one way or another
you *could* see the OpenMP library like a separate layer, at least for the
time being. Later we can think of optimising/integrating with
AST/whatever.

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

This is for sure a good point: if the design is generic enough we might
suffer less if the world decides to step away from OpenMP :-)

However, for the time being, I still believe that there are a few
advantages in having just OpenMP. The risk of being too general is that we
can come up with nothing at all, or we will produce something in a very
long time, while I think that it is not difficult to write explicitely in
POSIX threads the OpenMP functions that are in the specifications.

Biagio