On Mon, Apr 22, 2013 at 05:05:03PM -0500, Aldy Hernandez wrote:
> On 04/19/13 08:29, Jakub Jelinek wrote:
> >I've committed the following patch to gomp4 branch.
> >#pragma omp simd loops now are handled with all its clauses from parsing up
> >to and including omp expansion, so should actually run correctly, though
> >haven't added any runtime testcases yet.
>
> I like it. Thanks for working on this.
>
> I've been working on rewriting the <#pragma simd> support on the
> cilkplus branch to use a similar approach to what you do for openmp,
> especially since both constructs seem to behave similarly, with the
> exception of the "vectorlength" clause in Cilk Plus. Attached is a
> patch against yours, doing so.
>
> The idea is that <#prama omp simd> and <#pragma simd> are pretty
> much the same thing, so we can probably get away with outputting the
> same OMP_SIMD tree code and letting omp do it's thing.
I don't think you can use OMP_SIMD resp. GF_OMP_FOR_KIND_SIMD for
#pragma simd, given that it has different semantics wrt. aliasing.
Like:
void
foo (int *p, int *q)
{
int i;
#pragma omp simd
for (i = 0; i < 1024; i++)
p[i] = q[i] + 1;
}
vs.
void
bar (int *p, int *q)
{
int i;
#pragma simd
for (i = 0; i < 1024; i++)
p[i] = q[i] + 1;
}
It is a user error if one calls foo say with int arr[1028]; ... foo (arr + 4,
arr);
because through #pragma omp simd without safelen the programmer has asserted
that all iterations can be executed in the same simd chunk (think about 4096
bytes long vectors in this case). So, #pragma omp simd expansion should be
able to tell the vectorizer that it can ignore all inter-iteration
dependencies during analysis.
If I understood right, vectorlength isn't anything close to it, it is just a
hint, if you vectorize, prefer this vector length, but the compiler is still
responsible for doing the analysis, and punting if it can't prove there is
no aliasing (or go for runtime checks).
There is #pragma ivdep in ICC, but it's definition is vague - the compiler
is still supposed to do analysis, but if some dependency isn't certain, it
can assume it doesn't happen (which is the fuzzy thing about it, if the
compiler can prove there is some dependency, then the code is valid and
vectorization can't be done).
So, IMHO you want CILK_SIMD tree (but it can use OMP and CILK clauses etc.),
and GF_OMP_FOR_KIND_CILK_SIMD or so, and perhaps it can be expanded etc.
exactly the same as #pragma omp simd, except for not telling the loop
optimizers that it should imply safelen(+infinity). Or another option
is let the C/C++ FEs, when seeing #pragma omp simd without safelen clause
just add one with some very large value (unsigned TYPE_MAX_VALUE of
a type with precision > precision of the loop iterator?).
BTW, what restrictions has Cilk+ on the for stmt after the pragma?
OpenMP has lots of restrictions, it doesn't allow arbitrary for stmt there.
Like is
int i, j, k;
#pragma simd
for (i = 0, j = 4, k = 5; i < 10 && j < 12; i++, j += 2, k += 3)
...
valid Cilk+? It isn't valid with #pragma omp simd...
Jakub
