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

[Steven Bosscher]

Op do 30-01-2003, om 23:53 schreef Pop Sébastian:
> On Thu, Jan 30, 2003 at 09:34:08AM -0500, Diego Novillo wrote:
> > On Thu, 30 Jan 2003, Lars Segerlund wrote:
> > 
> > >  They handle the OpenMP stuff to libcalls after some optimizations ( 
> > > how do you spell this ? ), thus in the GIMPLE->RTL phase. However some 
> > > work has to be done before this !
> > > 
> > >  Also they don't generate subroutines which are executed in parallell, 
> > > they generate a 'reentrant code section' with shared locals available to 
> > > all threads, and a copy in/out scheme for private ( real local variables 
> > > , for thae thread ).
> > > 
> > Yes, that's correct.  Those are all code generation tricks that
> > are to be expected.  All these should be done *after* we are done
> > analysing and transforming the input program.  That's done in the
> > GIMPLE->RTL phase, 
> 
> OMP lowering doesn't imply tree optimizations.
> Thus I think that we should lower OMP on GENERIC trees.
> For the first implementations of GOMP we want to just make it work without 
> too much worying about GIMPLE and optimizations. 

Are we not just all talking about the same thing here?

Diego's talking about making the GIMPLE optimizers concurrency-aware. 
That's not the same thing as OpenMP-aware.  Making the optimizers aware
of concurrency would provide good infrastructure for the future, but we
don't really need it now for an initial implementation of OpenMP
support.

If what I just wrote is corrent, then am I right that we to agree on the
points in the following list?
- A language-independent OpenMP interface would be nice, but
  it's not a must. It may in fact not even be possible due to
  semantics differences between languages.
- We should implement concurrency in GCC via new tree codes.
- We need a library, and at some point these tree codes will
  have to be replaced with library calls.
- Tree optimizations are nice but not necessary for a first
  shot at this.  However, we should be careful not to come up
  with an implementation that would make it hard switch to
  using concurrency awareness in the optimizers once they're
  be available.

Comments?

OK, some more brainstorming:

Depending on how big the differences are, we could decide to drop the
idea of a language independent OpenMP interface. Does anybody know how
big the OpenMP semantics differences mentioned by Scott really are
between the specifications for C/C++ and Fortran? 

Actually, keeping all of OpenMP in the separate front ends may be the
better design choice even if the differences are really small.  Code for
parsing/analyzing OpenMP directives is specific to each front end
anyway, and like Diego suggested, we could introduce new tree codes *in
the parsers* already, e.g. a "for"-loop following a #pragma OMP for is
not parsed as just a normal FOR_STMT, but as a PARALLEL_FOR_STMT. 
PARALLEL_FOR_STMT would have to be able to express the semantics of the
OpenMP directive, but it should not be OpenMP-specific.

For the front ends, we'd really only need two different OpenMP-aware
pieces of code: One for Fortran, and the other one shared by C/C++.

In other words, you could say we'd "lower" OpenMP directives to tree
codes even before we get to GENERIC.  Those tree codes would be part of
generic, though, and we should be able to use the same tree codes for
all languages (that is, they're language independent).

The semantics differences would have to be resolved in the front ends,
and that's the proper place to do it.  If there is to be concurrency
awareness in the tree optimizers, then it should IMHO be independent of
OpenMP, so that languages that have their own concurrency (Java, Ada
have been mentioned) may benefit from this infrastructure too.

The next step would be to do the code transformations and insert the
library calls.  For that we can use the property of GIMPLE that it is a
subset of GENERIC.  We could write a first implementation embedded in
the pass where we lower GENERIC to GIMPLE.  Once we get the concurrency
awareness in GIMPLE, we could just move most of the code transforms and
libcall generation from here to a separate pass between GIMPLE and RTL.

(I'm not so worried about compile time impact of an extra pass. I think
anyone interested in parallel code is probably also much more interested
in runtime performance of the generated code...)
 
> The following is just science fiction :-)
> <SF>
>   Why I still want to keep OMP lowering before tree optimizations is because 
> we 
>   could run a concurency detection pass (specific to a well known lib 
> interface)
>   that will build the specific tree nodes needed by the optimizer.
>   (In fact this pass will promote lib calls to tree nodes with concurency 
> semantics.)
>   This way we could optimize not only OMP code, but also code written using 
> this 
>   library...  But as usual this will require some more work on the compiler 
> side, 
>   and simplify a little the work for GOMP.
> </SF>
> 

Ehh???  What lib interface? Can you explain this some more please?

Greetz
Steven