[llvm-dev] [LLVM] (RFC) Addition/Support of new Vectorization Pragmas in LLVM

Doerfert, Johannes via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 20 12:56:51 PDT 2019

I realize this is probably out of scope but I wanted to put this out
here if people consider to add ivdep.

On 08/20, Terry Greyzck wrote:
> The ivdep pragma is intended to assist automatic vectorization - 
> basically, automatic vectorization behaves as it normally does, but if 
> it gets into a spot where it finds a potential dependence, it continues 
> on rather than rejecting the loop.
> Reductions are part of cycle-breaking; one possible way to identify 
> potential reduction objects is that their address is provably invariant 
> with respect to the vectorized loop.  Some examples (assume 'i' is the 
> loop primary induction):
> x = x + b[i]
>     &x is invariant with respect to the 'i' vector loop, and can be a 
> reduction candidate
> a[0] = a[0] + b[i]
>     &a[0] is invariant with respect to the 'i' vector loop, and can be a 
> reduction candidate
> a[ix[i]] = a[ix[i]] + b[i]
>     &a[ix[i]] varies with respect to the 'i' vector loop, and is not a 
> reduction candidate
>        *  I am ignoring the end case here where all values of ix[i] are 
> identical
>        *  Without an ivdep, this would be considered a histogram (or 
> what Cray used to call 'vector update'), due to possible repeated values 
> in array 'ix'
>        *  With an ivdep, this becomes a gather, load and add followed by 
> a scatter
> When outer loop vectorization is considered, identifying vector 
> reductions becomes somewhat more complicated, and the simple invariant 
> address test is not always sufficient.  Examples on request, though that 
> is really a different (and possibly lengthy) discussion.

The ignored case is what I was asking about. Basically, I was wondering
how you explain when reduction dependences are needed to be resolved by
the vectorizer and when you ignore potential reduction dependences.

While I can see the appeal towards users, I dislike something like
"their address provably invariant". Provably invariant can change
depending on the surrounding, the analyses, and the transformations
applied. Let's say ix is, after some transformations, known to be a
uniform array, reduction handling becomes required, but if the
uniformity is not exposed before the vectorizer, the potential
dependences will be ignored, right?. I mean, if it worked for the user
and then something unrelated screwed up replacement of the ix[i] values
with constants (in the user code or in the compiler), then it is hard to

Do you see what I mean? Please let me know if I misunderstand how Cray
handles ivdep though.

> On 8/19/2019 10:30 AM, Doerfert, Johannes wrote:
> > Hi Terry,
> >
> > I'm curious.
> >
> >>     * Primarily ivdep allows ambiguous dependencies to be ignored, examples:
> >>         *  p[i] = q[j]
> >>         *  a[ix[i]] = b[iy[i]]
> >>         *  a[ix[i]] += 1.0
> >>
> >>     * ivdep still requires automatic detection of reductions, including
> >>       multiple homogeneous reductions on a single variable, examples:
> >>         *  x = x + a[i]
> >>         *  x = x + a[i]; if ( c[i] > 0.0 ) { x = x + b[i] }
> > How do you define the difference between
> >    a[ix[i]] += 1.0
> > and
> >    x += 1.0
> > as you require reduction detection for the latter but seem to ignore the
> > (histogram) reduction dependences for the former.
> >
> > Thanks,
> >    Johannes


Johannes Doerfert

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190820/22c7ceaf/attachment.sig>

More information about the llvm-dev mailing list