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

Mailing List "llvm-commits" via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 25 12:47:30 PDT 2016


llvm-commits added a comment.

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


http://reviews.llvm.org/D19002





More information about the llvm-commits mailing list