Re: [Gomp-discuss] Plan ... coments wanted !

[Steven Bosscher]

Op wo 29-01-2003, om 09:25 schreef Lars Segerlund:
> 
>   Hi,
> 
>    For those who are following the gomp list you know that I'm working 
> on a plan ( suggestion of a plan ) of how to extend gcc to support openMP.
> 
>    There are some issues that have come up that have exposed some 
> ignorance of mine regarding several issues, ( some gcc details, some 
> openMP details ), so I will try to thoroughly study the issues involved 
> during the weekend.
> 
>    If anybody has ideas or suggestions please send them to me in order 
> to  get to grips with as much as possible at the first shot at a plan 
> for the implementation, this in order not to have to redo a lot of work 
> later.
> 
>    What I strive for is some general point as follows:
> 
>     1. Start with the backend and code generation.

How would you test that work then?  Hmm, I think the first point you
brought up deserves a bit more attention...
 
>     2. Make it independent on the threading model at the level of the 
> front- and middle end. ( the last term nicely stolen from steve :-) thanks )
>
>     3. Reduce the front end to back end interface to a set of common 
> primitives, ( perhaps not possible, but desirable ).

Isn't it the whole idea to *make* it possible?  The interface should be
able to represent all of OpenMP, and it should be up to the front end to
fit stuff to this interface. I don't see why it would not be possible.

>     4. As far as possible simplify the work that has to be done in the 
> front end even if this means adding an additional 'layer' to gcc, and 
> thoroughly specify the constraints that have to be imposed by the 
> frontend in order to make this easy to integrate for the front end writers.
> 
>     5. Keep the threading model and implementation ( which lib a.s.o. ) 
> confined to as late in the code generating phase as possible.
> 

Certainly we don't want the compiler to have to deal with different
thread library interfaces at all?

Is there a way to make the library sort of "pure", in the sense that
there are functions that only have side-effects that we know about in
the OpenMP layer at compile time?  If so, maybe that's something we
should tell the compiler about, too.


<BRAINSTORM>
Lars' List, 1st point:
>     1. Start with the backend and code generation.

Say, we have:

Front-end --> Middle end (language independent) --> Backend

Assuming we're still talking about implementing this in the
GCC tree-optimizer framework, this translates to:

Front-end --> [ (GENERIC --> GIMPLE) --> RTL ] --> Assembly

That is, the middle-end is GENERIC, GIMPLE, RTL.  The intermediate
representation GENERIC is the first language-independent layer we
have.  GIMPLE is just lowered GENERIC, i.e. all of GIMPLE is part
of GENERIC.

Now, the approach I was thinking of is:

1. Pick the layer (or layers) where we want to implement OpenMP
   in. This is obviously crucial to get right the first time
   because it determines how much work is involved for this
   project, and how much of the existing code needs modification.

2. Define how to extend the intermediate representation in that
   layer and all layers before it to allow OpenMP information to
   be represented.  The smaller the extensions, the better. (tree
   annotations?).
   Not as crucial to get right the first time, but it should
   not change too much.

3. Implement stubs for all of OpenMP.  Just some functions that
   understand the OpenMP information, but don't do anything with
   it.  Easy to change if we do 1. and 2. right.  We can replace
   them one by one with more useful code as we're progressing.
  
4. Make sure everything between the OpenMP layer and the front
   end understands and propagates the OpenMP information.  Again,
   this is easy if we get 1. and 2. right.

5. Implement support for the OpenMP #pragmas in the C front end,
   (other front ends can be done later). This is pretty much 
   orthogonal to the first point, so those two could be done in
   parallel ;-)
   It should not be that hard to parse those #pragmas.  Question
   is how to propagate that information to the OpenMP layer. That
   is the second point in this list.  Something to be discussed
   with the GCC mailing list, I guess...

One thing to consider in the choice for the layer(s), is how far down
the compiler we can propagate OpenMP information without having to
define too many different representations for OpenMP information. IMO,
that rules out RTL because it would require propagating OpenMP from the
front end through GENERIC and GIMPLE to RTL; that's three different
representations, because RTL is a (too?) low level intermediate
representation that is nothing like GENERIC or GIMPLE.
I agree with Lars' 4th point that the work that has to be done in the
front end should be minimized. Ideally, the front ends would do nothing
with extra the information but just propagating it.  I think there was
agreement that the code transformations for OpenMP should be language
independent.  So the front ends are ruled out as potential
implementation layers.

That leaves us with GENERIC and GIMPLE.

A second thing to consider for the OpenMP layer, is what kind of
information we need to make good parallel loops (flow graph? data
dependence analysis? Function inlining?).  I'm not very familiar with
OpenMP yet, so I don't exactly know what assumptions the compiler is
allowed to make in the presence of OpenMP directives.  But I'd expect
that at least some data dependency information would have to be
available before you can safely parallelize the loop without changing
its semantics.

The final consideration I can think of is code quality.  If we go too
high-level, can we still generate good parallel loops?  Would we inhibit
some basic optimizations (e.g. can a constant be propagated over a call
to the OpenMP library)?  If we go too low, would that make the
implementation unnecessarilly complicated?

It's been said before, we could look at Open64 to see how they did
this.  It would be nice if somebody who knows that compiler could
explain that a bit (Pop? :-P).

For Intel, there's the article that was mentioned a while ago, or
http://www.intel.com/technology/itj/2002/volume06issue01/art04_fortrancompiler/p03_overview.htm
</BRAINSTORM>

Greetz
Steven