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

[Preston Briggs]

On Tue, Jul 2, 2013 at 4:57 PM, Arnold Schwaighofer <aschwaighofer at apple.com>
wrote:
> 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.

Yes, I realized my error while walking home.

> > 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.

Thanks for the summary.
I'll see if I can work though the code and get it straightened out.

Preston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130702/16eb0dbc/attachment.html>