[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