Re: [Gomp-discuss] Code generation

[Biagio Lucini]

Right, I know it was confusing, so I'll try to be clearer here.

Take for instance the example of the Intel compiler reported on the Linux
Journal. Your original code is

#define N 10000
void   ploop(void)
{
  int k, x[N], y[N], z[N];
  #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]);
  }
}

They transform it into

#define N 10000
void  ploop(void)
{
    int k, x[N], y[N], z[N];
    __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: return;
}

An aside: they say that the compiler is not based on S2S transformations,
but it generates instead annotated paraller code, for better optimisation.
This looks to me like S2S, so I guess that whatever you use for S2S
transformations can be recicled in the AST phase, somehow. That's why I
wanted to go first S2S: not as a goal, but as a tool to understand what we
need.

Now back to the problem: __kmpc_fork_call is a generic function, a
building block for parallelisation. From where could it possibly get the type
of k,x,y,z?

Does anybody have an idea? My bet is that the compiler does not work this
way: this is a trivial rewriting for an human being, but with my limited
skills it looks like a huge task for an authomatic tool. I would be
grateful to anybody that could provide me with an example implementation
of __kmpc_fork_call that works for any kind of the arguments...

Cheers
Biagio

On Mon, 24 Feb 2003, Steven Bosscher wrote:

> Op ma 24-02-2003, om 16:36 schreef Biagio Lucini:
> > I was thinking over the week end on how to perform a source-to-source
> > transformation from OpenMP to pthreads. I suppose that if I break this
> > problem into pieces, many of them would be reusable when the middle end
> > will analyze the OpenMP stuff. Now my problem concerns the type of the
> > variables. Consider for instance
>
> I think it is a good idea to start thinking about the code
> transformations we need.  First of all because we'll have to start doing
> them at some point in the compiler, but also because it would give us an
> idea of the extension we need to the GENERIC/GIMPLE intermediate
> representations (that is, the new tree codes).
>
> (Basically this would mean interpreting the semantics of the
> specification, and maybe develop algorithms for the code transformations
> in pseudo-code???)
>
> I think actually doing source-to-source transformations is not a good
> idea.
>
> > #pragma openmp parallel shared(list1) private(list2)
> >
> > At this point, list1 and list2 are characters. What I mean is that their
> > type could have been defined elsewhere, even on another source file.
> > Moreover, there might be also variables with the same name that have
> > nothing to do with the ones i am interested in (e.g. they have another
> > scope and omonomy is only an accident). It is not difficult to produce an
> > example that could mislead any source-to-source translation.
>
> IMHO, this is exactly the reason why the compiler can do a better job
> than a preprocessor.  In the compiler you know everything about the
> symbols in the source file.  A preprocessor would have to parse all
> declarations to know the same, and it it can do that point the
> preprocessor is already almost a source-to-source *compiler*, not really
> a preprocessor.
>
> Greetz
> Steven
>
>
>
>
> _______________________________________________
> Gomp-discuss mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gomp-discuss
>