This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: Add #pragma ivdep support to the ME and C FE

On Thu, Oct 17, 2013 at 10:07:43AM +0200, Richard Biener wrote:
> Which suggests we use
> #pragma GCC ivdep
> to not collide with eventually different semantics in existing programs
> that use variants of this pragma?

Yeah, perhaps.

> > Intel:
> > "The ivdep pragma instructs the compiler to ignore assumed vector dependencies.
> >  To ensure correct code, the compiler treats an assumed dependence as a proven
> >  dependence, which prevents vectorization. This pragma overrides that decision.
> >  Use this pragma only when you know that the assumed loop dependencies are safe
> >  to ignore."
> This suggests that _known_ dependences are still treated as dependences.
> But what is known obviously depends on the implementation which
> may not know that a[i] and a[i+1] depend but merely assume it.  Not
> a standard-proof definition of the pragma ;)

Very bad definition indeed.

> That said, safelen even overrides know dependences (but with unknown
> distance vector)! (that looks like a bug to me, or at least a QOI issue)

safelen is whatever the OpenMP 4.0 standard requires (and Cilk+ is I believe
just defering the description to the OpenMP 4.0 definition), and fortunately
the OpenMP 4.0 standard doesn't contain any so badly worded definition.
The actual wording is not that the <= safelen consecutive iterations can be
run in any order, but that they can be performed all together using
(possibly emulated) SIMD instructions.  Thus I think it is correct if we use
it for decisions if we can vectorize a loop (without versioning it for
alias), regardless of known vs. unknown dependencies - if we have known
dependencies that would result in known broken code, perhaps we should
warn?, but probably not for anything further, it should not affect aliasing
of scalar or vector loads/stores in the loop, etc.
Then I think we'd handle forward but not backward dependencies.  Given the
void ignore_vec_dep(int *a, int k, int c, int m)
  #pragma omp simd
  for (int i = 0; i < m; i++)
    a[i] = a[i + k] * c;
testcase, I think we'll handle it fine for k <= -m and k >= 0.
For k >= m obviously, there is no overlap and even runtime versioning for
alias would handle it right, for smaller k because the load (vector or
non-vector) will be before the store and we don't tell aliasing the two
don't alias.  We don't vectorize any load+store operations (expressed as one
stmt in GIMPLE; struct copies or atomic stmts), do we?  Those would be
a problem with the above.  If for anything else we place all the VF loads
where the original load was in the IL and all the VF stores where the
original store was in the IL, and just leave it to other passes to reorder
if they can prove it doesn't alias, we should be fine.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]