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

[Pop Sébastian]

On Wed, Jan 29, 2003 at 09:25:40AM +0100, Lars Segerlund wrote:
> 
>  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.
> 
Thanks a lot for your initiative, Lars!

>   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'd like to have is a goal: say we take a code that uses OMP and that 
compiles well with the current version of gcc, and work for making gcc 
produce threaded code.  (I have no preferences, thus if someone want to 
propose something...)  

I think that in the first time we'll have to transform 
this code by hand in the same way it was described in:
http://www.linuxjournal.com/article.php?sid=4885

Original code:
----
  #pragma omp parallel for private(k) shared(x,y,z) 
  for (k=0;  k<N; k++) {
    x[k] = x[k] * y[k] + workunit(z[k]);
  }
----

And after transformation:
----
    __kmpc_fork_call(loc, 
                     3, 
                     T-entry(_ploop_par_loop), 
                     x, y, z)
    goto L1: 
    T-entry _ploop_par_loop(loc, tid, 
                            x[], y[], z[]) {
       lower_k = 0;
       upper_k = N;
       __kmpc_for_static_init(loc, tid, STATIC, 
                              &lower_k, 
                              &upper_k, ...);  
       for (local_k=lower_k;  local_k<=upper_k; 
            local_k++)  {
          x[local_k] = x[local_k] * y[local_k] 
                       + workunit(z[local_k]); 
       }
       __kmpc_for_static_fini(loc, tid);
       T-return;
    }
  L1:;
----

or we could use another compiler that allows to dump its 
intermediate representations after it has transformed OMP directives, 
and just make GCC to produce the same code transformation.

As for the underlying library we could just use the same names the 
other compiler uses in the first step, then we'll modify functions names
as the libgomp progresses.

Thus I think that we could work in parallel on the compiler part and on the 
library part without too much dependences :-)

>   What I strive for is some general point as follows:
> 
>    1. Start with the backend and code generation.
> 
I think you're right.  This is the first step.
This step includes code generation and writing libgomp.

>    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 )
> 
I see this as beeing our long term goal.  
But on the other hand, if we produce code with calls to libgomp, then 
the threading model specificities are handled in the libgomp.

>    3. Reduce the front end to back end interface to a set of common 
> primitives, ( perhaps not possible, but desirable ).
> 
>    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.
> 
What about dealing with the treading model only in libgomp?
This way the compiler will not deal at all with these low level problems.