[llvm] r296992 - [SCEV] Decrease the recursion threshold for CompareValueComplexity

Sanjoy Das via llvm-commits llvm-commits at lists.llvm.org
Sun Mar 5 16:04:44 PST 2017


Hi Hans,

Do we have time to pick this for 4.0 (once the buildbots have cycled
through this change)?  It is a low risk fix for PR32142.

-- Sanjoy


On March 5, 2017 at 4:01:12 PM, Sanjoy Das via llvm-commits
(llvm-commits at lists.llvm.org) wrote:
> Author: sanjoy
> Date: Sun Mar 5 17:49:17 2017
> New Revision: 296992
>
> URL: http://llvm.org/viewvc/llvm-project?rev=296992&view=rev
> Log:
> [SCEV] Decrease the recursion threshold for CompareValueComplexity
>
> Fixes PR32142.
>
> r287232 accidentally increased the recursion threshold for
> CompareValueComplexity from 2 to 32. This change reverses that change
> by introducing a separate flag for CompareValueComplexity's threshold.
>
> Modified:
> llvm/trunk/lib/Analysis/ScalarEvolution.cpp
> llvm/trunk/unittests/Analysis/ScalarEvolutionTest.cpp
>
> Modified: llvm/trunk/lib/Analysis/ScalarEvolution.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/ScalarEvolution.cpp?rev=296992&r1=296991&r2=296992&view=diff
> ==============================================================================
> --- llvm/trunk/lib/Analysis/ScalarEvolution.cpp (original)
> +++ llvm/trunk/lib/Analysis/ScalarEvolution.cpp Sun Mar 5 17:49:17 2017
> @@ -132,10 +132,15 @@ static cl::opt AddOpsInlineThr
> cl::desc("Threshold for inlining multiplication operands into a SCEV"),
> cl::init(500));
>
> -static cl::opt
> - MaxCompareDepth("scalar-evolution-max-compare-depth", cl::Hidden,
> - cl::desc("Maximum depth of recursive compare complexity"),
> - cl::init(32));
> +static cl::opt MaxSCEVCompareDepth(
> + "scalar-evolution-max-scev-compare-depth", cl::Hidden,
> + cl::desc("Maximum depth of recursive SCEV complexity comparisons"),
> + cl::init(32));
> +
> +static cl::opt MaxValueCompareDepth(
> + "scalar-evolution-max-value-compare-depth", cl::Hidden,
> + cl::desc("Maximum depth of recursive value complexity comparisons"),
> + cl::init(2));
>
> static cl::opt
> MaxAddExprDepth("scalar-evolution-max-addexpr-depth", cl::Hidden,
> @@ -496,7 +501,7 @@ static int
> CompareValueComplexity(SmallSet, 8> &EqCache,
> const LoopInfo *const LI, Value *LV, Value *RV,
> unsigned Depth) {
> - if (Depth > MaxCompareDepth || EqCache.count({LV, RV}))
> + if (Depth > MaxValueCompareDepth || EqCache.count({LV, RV}))
> return 0;
>
> // Order pointer values after integer values. This helps SCEVExpander form
> @@ -583,7 +588,7 @@ static int CompareSCEVComplexity(
> if (LType != RType)
> return (int)LType - (int)RType;
>
> - if (Depth > MaxCompareDepth || EqCacheSCEV.count({LHS, RHS}))
> + if (Depth > MaxSCEVCompareDepth || EqCacheSCEV.count({LHS, RHS}))
> return 0;
> // Aside from the getSCEVType() ordering, the particular ordering
> // isn't very important except that it's beneficial to be consistent,
>
> Modified: llvm/trunk/unittests/Analysis/ScalarEvolutionTest.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/Analysis/ScalarEvolutionTest.cpp?rev=296992&r1=296991&r2=296992&view=diff
> ==============================================================================
> --- llvm/trunk/unittests/Analysis/ScalarEvolutionTest.cpp (original)
> +++ llvm/trunk/unittests/Analysis/ScalarEvolutionTest.cpp Sun Mar 5 17:49:17
> 2017
> @@ -465,7 +465,7 @@ TEST_F(ScalarEvolutionsTest, Commutative
> });
> }
>
> -TEST_F(ScalarEvolutionsTest, SCEVCompareComplexity) {
> +TEST_F(ScalarEvolutionsTest, CompareSCEVComplexity) {
> FunctionType *FTy =
> FunctionType::get(Type::getVoidTy(Context), std::vector(), false);
> Function *F = cast(M.getOrInsertFunction("f", FTy));
> @@ -532,6 +532,42 @@ TEST_F(ScalarEvolutionsTest, SCEVCompare
> EXPECT_NE(nullptr, SE.getSCEV(Acc[0]));
> }
>
> +TEST_F(ScalarEvolutionsTest, CompareValueComplexity) {
> + IntegerType *IntPtrTy = M.getDataLayout().getIntPtrType(Context);
> + PointerType *IntPtrPtrTy = IntPtrTy->getPointerTo();
> +
> + FunctionType *FTy =
> + FunctionType::get(Type::getVoidTy(Context), {IntPtrTy, IntPtrTy}, false);
> + Function *F = cast(M.getOrInsertFunction("f", FTy));
> + BasicBlock *EntryBB = BasicBlock::Create(Context, "entry", F);
> +
> + Value *X = &*F->arg_begin();
> + Value *Y = &*std::next(F->arg_begin());
> +
> + const int ValueDepth = 10;
> + for (int i = 0; i < ValueDepth; i++) {
> + X = new LoadInst(new IntToPtrInst(X, IntPtrPtrTy, "", EntryBB), "",
> + /*isVolatile*/ false, EntryBB);
> + Y = new LoadInst(new IntToPtrInst(Y, IntPtrPtrTy, "", EntryBB), "",
> + /*isVolatile*/ false, EntryBB);
> + }
> +
> + auto *MulA = BinaryOperator::CreateMul(X, Y, "", EntryBB);
> + auto *MulB = BinaryOperator::CreateMul(Y, X, "", EntryBB);
> + ReturnInst::Create(Context, nullptr, EntryBB);
> +
> + // This test isn't checking for correctness. Today making A and B resolve to
> + // the same SCEV would require deeper searching in CompareValueComplexity,
> + // which will slow down compilation. However, this test can fail (with LLVM's
> + // behavior still being correct) if we ever have a smarter
> + // CompareValueComplexity that is both fast and more accurate.
> +
> + ScalarEvolution SE = buildSE(*F);
> + auto *A = SE.getSCEV(MulA);
> + auto *B = SE.getSCEV(MulB);
> + EXPECT_NE(A, B);
> +}
> +
> TEST_F(ScalarEvolutionsTest, SCEVAddExpr) {
> Type *Ty32 = Type::getInt32Ty(Context);
> Type *ArgTys[] = {Type::getInt64Ty(Context), Ty32};
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>


More information about the llvm-commits mailing list