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

[Diego Novillo]

On Fri, 31 Jan 2003, Steven Bosscher wrote:

> 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.
> 
As a first step, you need enough smarts in the optimizers to not
mess things up.  That is, your optimizers should know not to
transform anything inside parallel sections of the program.

> 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.
> 
I agree with all your points.  For the last one, you have to be
careful not to have your optimizers trample all over the parallel
sections.  You can start by simply not running them.

> 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? 
> 
You definitely want to start with just one language.

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

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

> 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 tree codes can stay the same, each front end can give them
different semantics that get resolved in the GENERIC -> GIMPLE
phase.

> 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.
> 
Carefule there.  If the concurrency models are too different, you
may not be able to find a straightforward mapping.  Consider
Java's view of parallel processes.  You inherit from a Thread
class or mark things runnable (can't remember).  It's not a
simple #pragma.


Diego.