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

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed May 21 17:37:56 PDT 2014


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

    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
    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>

More information about the llvm-bugs mailing list