[llvm-bugs] [Bug 27691] New: SCEV is too conservative around proving no-overflow for loops without computable backedge counts

via llvm-bugs llvm-bugs at lists.llvm.org
Mon May 9 15:31:31 PDT 2016


https://llvm.org/bugs/show_bug.cgi?id=27691

            Bug ID: 27691
           Summary: SCEV is too conservative around proving no-overflow
                    for loops without computable backedge counts
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: sanjoy at playingwithpointers.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Currently the following logic is guarded under
!isa<SCEVCouldNotCompute>(MaxBECount), when I think it applies even if
MaxBECount is not computable.

        // If the backedge is guarded by a comparison with the pre-inc value
        // the addrec is safe. Also, if the entry is guarded by a comparison
        // with the start value and the backedge is guarded by a comparison
        // with the post-inc value, the addrec is safe.
        ICmpInst::Predicate Pred;
        const SCEV *OverflowLimit =
            getSignedOverflowLimitForStep(Step, &Pred, this);
        if (OverflowLimit &&
            (isLoopBackedgeGuardedByCond(L, Pred, AR, OverflowLimit) ||
             (isLoopEntryGuardedByCond(L, Pred, Start, OverflowLimit) &&
              isLoopBackedgeGuardedByCond(L, Pred, AR->getPostIncExpr(*this),
                                          OverflowLimit)))) {
          // Cache knowledge of AR NSW, then propagate NSW to the wide AddRec.
          const_cast<SCEVAddRecExpr *>(AR)->setNoWrapFlags(SCEV::FlagNSW);
          return getAddRecExpr(
              getExtendAddRecStart<SCEVSignExtendExpr>(AR, Ty, this),
              getSignExtendExpr(Step, Ty), L, AR->getNoWrapFlags());
        }

-- 
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/20160509/200a7fe2/attachment.html>


More information about the llvm-bugs mailing list