[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gomp-discuss] Code generation
From: |
Biagio Lucini |
Subject: |
Re: [Gomp-discuss] Code generation |
Date: |
Mon, 24 Feb 2003 18:12:56 +0000 (GMT) |
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
>