[PATCH] D19002: [LazyValueInfo] Fix for a nasty compile-time problem with questions

[Gerolf Hoflehner via llvm-commits]

Philip

the only code change is 

+  // FIXME: this is to solve a compile-time problem.
+  // In a test case with thousands of alloca's and
+  // indiect calls the solver pushed the allocas as undefined
+  // on the stack and tries to "solve" them. This seems to
+  // triggered that the value range problem in the current algorithm
+  // is not solved as a forward problem with well defined top, bottom, meet
+  // etc. Instead it may walk the CFG spontaneously in any direction and push
+  // values on the block stack while it tries to determine the lattice values
+  // of the values on the stack. This is illustrated in the current routine:
+  // solve -> solveBlockValue -> solveBlockValueNonLocal, which (see below)
+  // may call getEdgeValue, which in turn could push more values on the stack
+  // This code fixes the test cases with the alloca's reducing compile-time
+  // for that ~150K line funciton from "inifinite" to a couple of minutes.
+  // The rational is that "not null" is the best we can do for a stackaddress.
+
+  if (isa<AllocaInst>(Val)) {
+    assert(NotNull && "Stackaddress cannot be zero\n");
+    PointerType *PTy = cast<PointerType>(Val->getType());
+    Result = LVILatticeVal::getNot(ConstantPointerNull::get(PTy));
+    BBLV = Result;
+    return true;
+  }
+

I think you were ok with it in your first review. Can I get a LGTM just for that? I will then open a new review for remaining questions.

Thanks
Gerolf

> On Apr 19, 2016, at 7:22 PM, Gerolf Hoflehner <ghoflehner at apple.com> wrote:
> 
> Gerolf updated this revision to Diff 54314.
> Gerolf added a comment.
> 
> Mostly removed some of my questions and added a few comments based on Philip's
> review.
> 
> 
> http://reviews.llvm.org/D19002
> 
> Files:
>  lib/Analysis/LazyValueInfo.cpp
> 
> Index: lib/Analysis/LazyValueInfo.cpp
> ===================================================================
> --- lib/Analysis/LazyValueInfo.cpp
> +++ lib/Analysis/LazyValueInfo.cpp
> @@ -60,6 +60,10 @@
> /// FIXME: This is basically just for bringup, this can be made a lot more rich
> /// in the future.
> ///
> +/// Note:
> +/// constantrange applies only to integers. constant/notconstant applies to
> +/// non-integers, too.
> +
> namespace {
> class LVILatticeVal {
>   enum LatticeValueTy {
> @@ -240,6 +244,7 @@
> 
>     if (isNotConstant()) {
>       if (RHS.isConstant()) {
> +        // A value is different on two paths -> mark as bottom (overdefined)
>         if (Val == RHS.Val)
>           return markOverdefined();
> 
> @@ -748,6 +753,29 @@
>     }
>   }
> 
> +  // FIXME: this is to solve a compile-time problem.
> +  // In a test case with thousands of alloca's and
> +  // indiect calls the solver pushed the allocas as undefined
> +  // on the stack and tries to "solve" them. This seems to
> +  // triggered that the value range problem in the current algorithm
> +  // is not solved as a forward problem with well defined top, bottom, meet
> +  // etc. Instead it may walk the CFG spontaneously in any direction and push
> +  // values on the block stack while it tries to determine the lattice values
> +  // of the values on the stack. This is illustrated in the current routine:
> +  // solve -> solveBlockValue -> solveBlockValueNonLocal, which (see below)
> +  // may call getEdgeValue, which in turn could push more values on the stack
> +  // This code fixes the test cases with the alloca's reducing compile-time
> +  // for that ~150K line funciton from "inifinite" to a couple of minutes.
> +  // The rational is that "not null" is the best we can do for a stackaddress.
> +
> +  if (isa<AllocaInst>(Val)) {
> +    assert(NotNull && "Stackaddress cannot be zero\n");
> +    PointerType *PTy = cast<PointerType>(Val->getType());
> +    Result = LVILatticeVal::getNot(ConstantPointerNull::get(PTy));
> +    BBLV = Result;
> +    return true;
> +  }
> +
>   // If this is the entry block, we must be asking about an argument.  The
>   // value is overdefined.
>   if (BB == &BB->getParent()->getEntryBlock()) {
> 
> 
> <D19002.54314.patch>