Re: [Gomp-discuss] Code generation

[Steven Bosscher]

Op ma 24-02-2003, om 19:12 schreef 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.

Well, if you look at things like that, any compiler is a
source-to-source compiler, except maybe assemblers, which I really
wouldn't classify as compilers anyway.

All code transformations in the compiler are performed on some
intermediate representation with certain semantics, and ideally you
would be able to dump that intermediate representation in a
human-readable form.  For example, GCC translates, say, C++ to GENERIC,
GIMPLE, RTL and finally assembly.  It is only for political reasons that
GENERIC, GIMPLE and RTL can't be dumped to C.

(In fact, a back end that writes C instead of assembly exists, but isn't
integrated, again that's FSF politics (which, for the record, I
support)).

Apparently Intel has the ability to dump something C-ish after code
transformations.  Good for us I would say ;-)  Note that this dump does
not look like compilable code, just an intermediate representation that
looks like C so it's easy to read.

Of course if you don't ask for a dump, you'll never see these internals,
and you'll get a binary instead.  So they compile source-to-binary and
their statement is perfectly OK, of course.

> 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?

>From the OpenMP specifications, "k" *must* be an integer, so that one is
easy.  My guess is that "x", "y", and "z" are cast to (void *).

Actually I'm surprised to see that they pass those variables at all. 
There doesn't seem to be anything particularly special about them.  It
looks like they pass all arrays in the loop to their init and fork
functions.  Maybe they use it for some kind of checking (dependence,
bounds, who knows).  Or maybe they just dump them to say, hey these are
used in this parallel loop.

Greetz
Steven


 
> 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
> >
> 
> 
> _______________________________________________
> Gomp-discuss mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gomp-discuss