[PATCH] Loop Rerolling Pass

Andrew Trick atrick at apple.com
Thu Oct 17 09:31:43 PDT 2013


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

> ----- Original Message -----
>> 
>> 
>> 
>> On Oct 16, 2013, at 6:25 PM, Andrew Trick < 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)
>> 
>> 
>> Of course, in either case, the loop may exit earlier via another exit
>> or terminate early.
> 
> This makes sense. Maybe something as simple as getBackedgeTakenCount(bool MayExitElsewhere = true)?

Sure. As long as the comments make it clear.

Internally, SCEV has a per-exit BECount object that will need to know whether it has a may-exit or must-exit count.
-Andy

> 
> -Hal
> 
>> 
>> 
>> -Andy
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131017/f0dcfdc4/attachment.html>


More information about the llvm-commits mailing list