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

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

> >  I have a suspicion that we might be able to target GENERIC and 
> > generate  annotated GIMPLE, how does this sound ? ( This is one part 
> > which I need to read up on, sorry my understanding of some issues are 
> > lacking ).
> > 
> You don't annotate the trees if at all possible.  Create new tree
> codes that have the exact semantics you want.  What I mean by
> this:  Suppose you want to mark a parallel loop.  You don't just
> annotate a LOOP_EXPR.  You create a new tree node called
> FORALL_EXPR (or whatever suitable name).
> 
> That is a lot cleaner and easier to handle than arbitrary
> annotations.  Annotations should be reserved for attributes and
> secondary data that you want to associate to a tree.
> 
I agree on this point.

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>