[llvm] r184684 - LoopVectorize: Add utility class for checking dependency among accesses

[Arnold Schwaighofer]

On Jul 2, 2013, at 4:55 PM, Preston Briggs <preston.briggs at gmail.com> wrote:

> On Mon, Jul 1, 2013 at 1:43 PM, Preston Briggs <preston.briggs at gmail.com> wrote:
> > Arnold Schwaighofer <aschwaighofer at apple.com> wrote:
> > > I have taken a high-level look at the implementation of the Dependence Analysis pass. 
> > > - Overflow
> > > It seems the current implementation does not handle overflow correctly.
> >
> > I can believe it. I think this whole question needs to be carefully discussed and reviewed.
> > I certainly don't understand all the constraints.
> >
> > > We must be very careful with cases where part of the access function might overflow.
> > >
> > > ;;  for (long unsigned i = 0; i < N; i++) {
> > > ;;    A[3*i+7] = i;
> > > ;;    *B++ = A[3*i];
> > >
> > > There is a dependence between the two access possible due to integer wrapping
> > > but the current implementation returns there is none. I have not investigated why.
> >
> > At a glance, I would think there's no possible dependence,
> > since GCD(3, 3) => 3 which doesn't divide 7.
> > That's as far as the current analysis will go.
> >
> > But of course your point is correct.
> 
> On 2nd thought, I disagree; I don't believe there's a dependence.
> My argument is that "i" can never wrap
> (since it's incremented by 1 and compared against "N”)

It is not “i” in this case that can wrap but the computation of the index into the array.
“3*i” will wrap if N is big enough.

> Can't we notice this by paying attention to the nowrap flags
> associated with the SCEV?  That said, it's not clear to me that
> I do the right thing. Nevertheless, it gives me hope for the future.


Yes we can detect safety by looking at the wrap flags in the IR or at the SCEV in many cases.

Only in some cases do we have to give up:

Signed integer arithmetic does not wrap (sloppy; it is undefined behavior) so if the expressions add(3*i, 7), and 3*i have the nsw attribute we are good (this would not be the case in my example, of course, it was carefully chosen to be a pain in the neck ;). We can also look at the SCEV of the pointer, it might have a nowrap flag, in which case we are good.

For unsigned arithmetic (absence of nowrap flags):
1.) try to show the expression cannot wrap if loop bounds are known
2.) insert dynamic checks
3.) finally give up

In the case above the only thing we can do is insert dynamic checks or ask the programmer to use signed integers instead of unsigned integer communicating to the compiler that he knows that the computations will not wrap.