[PATCH] Loop Rerolling Pass

[Andrew Trick]

On Oct 20, 2013, at 12:11 PM, Nick Lewycky <nicholas at mxc.ca> wrote:

> Andrew Trick wrote:
>> 
>> On Oct 16, 2013, at 6:25 PM, Andrew Trick <atrick at apple.com
>> <mailto:atrick at apple.com>> wrote:
>> 
>>>> But it seems, that being the case, we could still return 'n/5' for
>>>> loops with only one exiting block? I thought that is what
>>>> SE->hasLoopInvariantBackedgeTakenCount(L) was for. It would only say
>>>> that there was a backedge-taken count if the loop structure was
>>>> simple enough that there was one unambiguous answer. Is this just an
>>>> implementation oversight, or are there additional complications?
>>>> 
>>>>> 
>>>>> So you could get a minimum taken count for a particular loop back
>>>>> edge in this case if we adapt the SCEV API to communicate properly.
>>>> 
>>>> I recall discussing this before, and so I apologize, but can you
>>>> elaborate on what 'communicate properly' will entail?
>>> 
>>> I’m open to anything. For each branch exit we could distinguish
>>> between a min vs. exact backedge taken count.
>> 
>> Minimum taken count is the wrong term. We have either an
>> “exact-may-exit” count or an “exact-must-exit” count. The implication of
>> exact-may-exit is that either:
>> - the loop exits at this iteration
>> - the loop exits at a later iteration via another exit
>> - the loop terminates at a later iteration
>> - the loop exhibits undefined behavior (at a later iteration)
> 
> One more case:
> 
> - the loop either exits here, or does not terminate

The case I left out, which you may be alluding to: the loop makes a non-readonly call to a function with a legitimate infinite loop.

(The established precedent is that readonly calls are not expected to terminate or infinite-loop.)

-Andy