[PATCH] Loop Rerolling Pass

[Andrew Trick]

On Oct 17, 2013, at 11:47 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> 
>> 
>> 
>> On Oct 17, 2013, at 11:33 AM, Hal Finkel < hfinkel at anl.gov > wrote:
>> 
>> 
>> 
>> ----- Original Message -----
>> 
>> 
>> 
>> 
>> 
>> On Oct 17, 2013, at 10:30 AM, Hal Finkel < hfinkel at anl.gov > wrote:
>> 
>> 
>> 
>> 
>> If the loop is testing less-than constant ’n’, I think we already
>> handle it (knowing n < INT_MAX-stride). I’m not sure what we do for
>> equals ’n’.
>> 
>> No, that does not currently work. Compiling the following with clang:
>> 
>> void foo(int n, int *x) {
>> for (int i = 0; i < n; i += 3) {
>> x[i] = i;
>> x[i+1] = i+1;
>> x[i+2] = i+2;
>> }
>> }
>> 
>> I find that SE->hasLoopInvariantBackedgeTakenCount(L) returns false.
>> From what you're saying, this sounds like a bug, no?
>> 
>> By “constant n” I meant “a constant” ;)
>> 
>> Right, and the constant case works. The variable case does not, and
>> if I understand correctly, this is the 'we ignore the nsw flag'
>> case. If we get to assume that i += 3 does not wrap, then we can
>> positively return a backedge taken count of n/3-1, right?
>> 
>> You had also said that we need to make clear what the number returned
>> means (because we can't actually guarantee that many iterations in
>> the face of functions that might throw, etc.), but I don't see how
>> this interpretation concern is affected by whether or not n is a
>> constant. Are these two issues related?
>> 
>> 
>> Ah. When I say the “constant” case is handled, I mean we know that we
>> must take the exit at iteration n/3. For a nonconstant, we may exit
>> at n/3 or may terminate later via a call, exit later via a different
>> loop test, etc. If the client can prove that there’s no other way
>> for the loop to terminate or exit, then it can use n/3 as the trip
>> count.
> 
> Okay; we need to stop overloading our terminology here. How about I'll say that currently SE->hasLoopInvariantBackedgeTakenCount(L) returns false on the aforementioned loop when n is a runtime value, and true when n is a compile-time value. And, assuming that we have nsw on the increment (or nuw for an unsigned latch comparison), this is a bug, correct?

Returning true for hasLoopInvariantBackedgeTakenCount would be a correctness bug in rare cases. Even if the loop has a no other exits, it may call exit(), throw an exception,so forth without undefined behavior.

I’m concerned that we won’t be able to explain the new API to other developers. Lets see if we can agree on a potential API offline then come back to the list when we’re speaking the same language. 

-Andy