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

[Diego Novillo]

On Wed, 29 Jan 2003, Lars Segerlund wrote:

>  Now as for treelang, I didn't mean that we would use treelang, just 
> something like it, preferably more simple.
> 
You really want to work on GIMPLE.  That's the language over
which GCC will do tree optimizations.

For my thesis work, I had to analyze and optimize languages with
explicit parallel constructs.  It wasn't OpenMP, but it had two
of the main constructs: cobegin/coend and forall.

I was using SUIF at the time.  SUIF's IL is roughly similar to
GIMPLE.  What I did is model cobegin/coend with multiway branches
(ie, switch() statements) and forall with regular for() loops.

Since I didn't have #pragma controls, I implemented the language
bits using #defines:

#define cobegin                 switch (__ODC_cobegin)
#define parloop(v,lb,ub)        for (__ODC_parloop = lb, ...)

The compiler would look for __ODC_cobegin and __ODC_parloop to
know which sections of the code were supposed to be parallel.
The code generator would then wrap the bodies of those loops into
calls to the SUIF runtime.

That approach worked very well for me.  I could concentrate on
the real work (analyzing and optimizing the parallel sections)
without worrying too much about the runtime/language issues.

For GOMP I'd suggest:

- Determine which expressions need to be introduced at the
  intermediate language level (GIMPLE).  I am not terribly
  familiar with OpenMP, but it shouldn't be more than a handful
  of different expressions: one or two flavours of parallel
  loops, a parallel section a-la cobegin/coend, and some locking
  primitives.  This should be done with the OpenMP spec on the
  side, of course.

- The parser will simply turn OpenMP #pragmas into the expression
  trees we defined above.

- It is important to realize that the concurrency semantics are
  *not* dictated by the runtime.  They are dictated by the
  expression trees that we define from the OpenMP specs.  The
  runtime must follow those semantics, not dictate them.

- The code generator should generate calls to a libgomp runtime
  that will map those calls to the lower-level runtime.  I
  suggest that we do the first lower-level runtime using the new
  posix threads (NPTL).  That's where all GNU software will go in
  the near future.  It's a natural target for glibc.

As far as the optimizations go, almost everything will be
analyzed and optimized at the GIMPLE level.  I can't see many
things percolating down to RTL.  The high-level semantics of the
OpenMP directives will be translated to calls into a runtime and
things like memory barriers to stop the RTL optimizers from
messing around in parallel sections too much.


Diego.