it. Also, not sure what to do for lastprivate, probably use the magic
arrays and just in the epilogue of the loop compute which of the array items
belonged to the last iteration somehow.
Can't you do (for lastprivate(abc) something like:
if (i == 1024) {
abc = magic_abc[__builtin_GOMP.simd_lane (1)];
}
#pragma omp declare simd
__attribute__((noinline, noclone)) void
bar (int &x, int &y)
{
x += 4;
y += 4;
}
Does bar() have anything to do with this example, or was this an oversight?
using the magic arrays and so is reduction. While the vectorizer can
recognize some reductions, e.g. without -ffast-math it will not vectorize
any floating point ones because that means changing the order of
computations, while when they are mandated to be one copy per simd lane,
the order of computations is clear and thus can be vectorized.
Let me see if I understand (all things floating point confuse me).
You're saying that the vectorizer, in its present state will refuse to
vectorize reductions with floats because it may possibly change the
order of computations, but we should override that behavior for OMP simd
loops?
D.2717[D.2714].s = D.2702;
D.2703 = b[i];
a.0 = a;
D.2705 = a.0 + x;
D.2701 = D.2717[D.2714].s;
Is there some subtlety in which we have to dereference D.2717 twice
here, or can we reuse D.2702?
Aldy
