[LLVMbugs] [Bug 19799] Indvars miscompile due to an incorrect max backedge taken count from SCEV.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19799

Andrew Trick <atrick at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |atrick at apple.com
                   |org                         |

--- Comment #9 from Andrew Trick <atrick at apple.com> ---
Fixed in r209358.

Author: Andrew Trick <atrick at apple.com>
Date:   Wed May 21 17:23:48 2014

    Fix a bug in SCEV's backedge taken count computation from my prior fix in
Jan.

    This has to do with the trip count computation for loops with multiple
    exits, which is quite subtle. Most passes just ask for a single trip
    count number, so we must be conservative assuming any exit could be
    taken.  Normally, we rely on the "exact" trip count, which was
    correctly given as "unknown". However, SCEV also gives a "max"
    back-edge taken count. The loops max BE taken count is conservatively
    a maximum over the max of each exit's non-exiting iterations
    count. Note that some exit tests can be skipped so the max loop
    back-edge taken count can actually exceed the max non-exiting
    iterations for some exits. However, when we know the loop *latch*
    cannot be skipped, we can directly use its max taken count
    disregarding other exits. I previously took the minimum here without
    checking whether the other exit could be skipped. The correct, and
    simpler thing to do here is just to directly use the loop latch's max
    non-exiting iterations as the loops max back-edge count.

    In the problematic test case, the first loop exit had a max of zero
    non-exiting iterations, but could be skipped. The loop latch was known
    not to be skipped but had max of one non-exiting iteration. We
    incorrectly claimed the loop back-edge could be taken zero times, when
    it is actually taken one time.

    Fixes Loop %for.body.i: <multiple exits> Unpredictable backedge-taken
count.
    Loop %for.body.i: max backedge-taken count is 1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140522/11ab68fc/attachment.html>