[LLVMbugs] [Bug 21622] New: [SCEV] New Trip Count Computation cause Overflow assertion in MachineBlockFrequency

[bugzilla-daemon at llvm.org]

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

            Bug ID: 21622
           Summary: [SCEV] New Trip Count Computation cause Overflow
                    assertion in MachineBlockFrequency
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: zhaoshiz at codeaurora.org
                CC: apazos at codeaurora.org, chandlerc at gmail.com,
                    llvmbugs at cs.uiuc.edu, mcrosier at codeaurora.org
    Classification: Unclassified

Created attachment 13380
  --> http://llvm.org/bugs/attachment.cgi?id=13380&action=edit
C Test case

> clang --target=aarch64-linux-gnu  -mcpu=cortex-a57 -Ofast test.c -mllvm -unroll-allow-partial -mllvm -unroll-threshold=1000 -c -o test.o
> clang-3.6: /prj/llvm-arm/home/nightly/src/community-mainline/llvm/lib/Analysis/BlockFrequencyInfoImpl.cpp:125: void combineWeight({anonymous}::Weight&, const Weight&): Assertion `W.Amount < W.Amount + OtherW.Amount && "Unexpected overflow"' failed.

The commit below changes how SCEV computes loop trip count:

> -    dyn_cast<SCEVConstant>(getBackedgeTakenCount(L));
> +      dyn_cast<SCEVConstant>(getExitCount(L, ExitingBlock));

This results in a loop previously considered runtime (trip count is 0) becomes
a compile time loop (trip count is 255).

With '-unroll-allow-partial' and '-unroll-threshold=1000', loop unroll pass
chooses to unroll this loop by a factor of 85.

As a result, a substantial number of branches are targeting the same landing
block, eventually overflow BlockFrequency calculation.


commit ed05e3703e07dfeae33acdd3cc5ad07b5f5b86c6
Author: Mark Heffernan <meheff at google.com>
Date:   Fri Oct 10 10:39:11 2014

    This patch de-pessimizes the calculation of loop trip counts in
    ScalarEvolution in the presence of multiple exits. Previously all
    loops exits had to have identical counts for a loop trip count to be
    considered computable. This pessimization was implemented by calling
    getBackedgeTakenCount(L) rather than getExitCount(L, ExitingBlock)
    inside of ScalarEvolution::getSmallConstantTripCount() (see the FIXME
    in the comments of that function). The pessimization was added to fix
    a corner case involving undefined behavior (pr/16130). This patch more
    precisely handles the undefined behavior case allowing the pessimization
    to be removed.

    ControlsExit replaces IsSubExpr to more precisely track the case where
    undefined behavior is expected to occur. Because undefined behavior is
    tracked more precisely we can remove MustExit from ExitLimit. MustExit
    was used to track the case where the limit was computed potentially
    assuming undefined behavior even if undefined behavior didn't necessarily
    occur.


    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219517
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
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/20141121/6e8bc4eb/attachment.html>