<div dir="ltr">On Tue, Jul 2, 2013 at 4:57 PM, Arnold Schwaighofer <<a href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>> wrote:<br>> On Jul 2, 2013, at 4:55 PM, Preston Briggs <<a href="mailto:preston.briggs@gmail.com">preston.briggs@gmail.com</a>> wrote:<br>
> > On Mon, Jul 1, 2013 at 1:43 PM, Preston Briggs <<a href="mailto:preston.briggs@gmail.com">preston.briggs@gmail.com</a>> wrote:<br>> > > Arnold Schwaighofer <<a href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>> wrote:<br>
> > > > I have taken a high-level look at the implementation of the Dependence Analysis pass.<br>> > > > - Overflow<br>> > > > It seems the current implementation does not handle overflow correctly.<br>
> > ><br>> > > I can believe it. I think this whole question needs to be carefully discussed and reviewed.<br>> > > I certainly don't understand all the constraints.<br>> > ><br>> > > > We must be very careful with cases where part of the access function might overflow.<br>
> > > ><br>> > > > ;;  for (long unsigned i = 0; i < N; i++) {<br>> > > > ;;    A[3*i+7] = i;<br>> > > > ;;    *B++ = A[3*i];<br>> > > ><br>> > > > There is a dependence between the two access possible due to integer wrapping<br>
> > > > but the current implementation returns there is none. I have not investigated why.<br>> > ><br>> > > At a glance, I would think there's no possible dependence,<br>> > > since GCD(3, 3) => 3 which doesn't divide 7.<br>
> > > That's as far as the current analysis will go.<br>> > ><br>> > > But of course your point is correct.<br>> ><br>> > On 2nd thought, I disagree; I don't believe there's a dependence.<br>
> > My argument is that "i" can never wrap<br>> > (since it's incremented by 1 and compared against "N”)<br>><br>> It is not “i” in this case that can wrap but the computation of the index into the array.<br>
> “3*i” will wrap if N is big enough.<div><br></div><div style>Yes, I realized my error while walking home.</div><div><br>> > Can't we notice this by paying attention to the nowrap flags<br>> > associated with the SCEV?  That said, it's not clear to me that<br>
> > I do the right thing. Nevertheless, it gives me hope for the future.<br>><br>> Yes we can detect safety by looking at the wrap flags in the IR or at the SCEV in many cases.<br>> Only in some cases do we have to give up:<br>
><br>> Signed integer arithmetic does not wrap (sloppy; it is undefined behavior)</div><div>> so if the expressions add(3*i, 7), and 3*i have the nsw attribute we are good</div><div>> (this would not be the case in my example, of course, it was carefully chosen</div>
<div>> to be a pain in the neck ;). We can also look at the SCEV of the pointer,</div><div>> it might have a nowrap flag, in which case we are good.<br>><br>> For unsigned arithmetic (absence of nowrap flags):<br>
> 1.) try to show the expression cannot wrap if loop bounds are known<br>> 2.) insert dynamic checks<br>> 3.) finally give up<br>><br>> In the case above the only thing we can do is insert dynamic checks</div>
<div>> or ask the programmer to use signed integers instead of unsigned integer</div><div>> communicating to the compiler that he knows that the computations will not wrap.<br><br>Thanks for the summary.</div><div>I'll see if I can work though the code and get it straightened out.</div>
<div><br></div><div>Preston</div><div><br><br><div class="gmail_extra"><br></div></div></div>