[PATCH] D32135: [LVI Printer] Rely on the LVI analysis functions rather than the LVI cache

[Anna Thomas via Phabricator via llvm-commits]

anna added inline comments.


================
Comment at: test/Analysis/LazyValueAnalysis/lvi-after-jumpthreading.ll:59
-; CHECK: br i1 %cnd, label %backedge, label %exit
-loop:
-  %iv = phi i32 [0, %entry], [%iv.next, %backedge]
----------------
I will add this test in a follow up functional change to LVI code itself: change LVI result and remove an assert that triggers when we call `getValueInBlock(%iv2.next, loop)`. This seems a valid call because `%iv2.next` is used in the basic block `loop`, which means it's already defined. When printing LVI for `iv2.next` at block `loop`, we currently fail on the assert in:
```
bool LazyValueInfoImpl::solveBlockValueNonLocal(..){
if (BB == &BB->getParent()->getEntryBlock()) {
    assert(isa<Argument>(Val) && "Unknown live-in to the entry block");
}
```
The assert makes sense (call solveBlock for values in entry block works only iff it is defined in the entry block OR is a function argument). However, `LVI::solve` function for `(iv2.next, loop)` recurses over the predecessors of the `loop` block, and this includes the entry block.  

Note: We don't trigger this solve in the Jumpthreading or CVP usage of LVI. But it seems a perfectly reasonable solve to trigger. 



https://reviews.llvm.org/D32135