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

[Biagio Lucini]

Hi,

        from the good analysis made by Steven it seems to me that probably
Gimple is the best place to do the big job. Ideally, all information
propagates from the front-end to that stage, where it is analysed 
and optimised.

I've started to glance the code of Open64, since they don't have a working
implementation of OpenMP yet it is difficult to understand what they have
done. One of my plans was to join there list, discuss a few topic with
them and invite the interested people to join our list. Hope I can do it
soon.

Biagio

On 29 Jan 2003, Steven Bosscher wrote:

> 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
> 
> 
> 
> 
> _______________________________________________
> Gomp-discuss mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gomp-discuss
>