[llvm] r184684 - LoopVectorize: Add utility class for checking dependency among accesses
Preston Briggs
preston.briggs at gmail.com
Tue Jul 2 14:55:07 PDT 2013
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").
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.
Preston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130702/07b4fc94/attachment.html>
More information about the llvm-commits
mailing list