This is an archive of the discontinued LLVM Phabricator instance.

[LVI Printer] Rely on the LVI analysis functions rather than the LVI cache
ClosedPublic

Authored by anna on Apr 17 2017, 1:53 PM.

Details

Summary

LVIPrinter pass was previously relying on the LVICache. We now directly call the
the LVI functions which solves the value if the LVI information is not already
available in the cache. This has 2 benefits over the printing of LVI cache:

  1. higher coverage (i.e. catches errors) in LVI code paths.
  2. relies on the core functions, and not dependent on the LVI cache (which may

be scrapped at some point).
It would still catch any cache invalidation errors, since we first go through
the cache.

*Thanks to Philip for this suggestion, instead of relying on LVI cache for printing*

Diff Detail

Repository
rL LLVM

Event Timeline

anna created this revision.Apr 17 2017, 1:53 PM
anna added inline comments.Apr 17 2017, 2:07 PM
test/Analysis/LazyValueAnalysis/lvi-after-jumpthreading.ll
59 ↗(On Diff #95481)

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.

anna edited the summary of this revision. (Show Details)Apr 17 2017, 2:07 PM
anna edited the summary of this revision. (Show Details)
sanjoy added inline comments.Apr 20 2017, 4:01 PM
lib/Analysis/LazyValueInfo.cpp
1904 ↗(On Diff #95481)

Is it legal to call getValueInBlock(I, BB) if I does not domiate BB? If it isn't legal, then the code above will not do the right thing in cases like:

  br cond, L, R

L:
  %v = def
  br R

R:

since you'll end up asking getValueInBlock(%v, R) when %v does not dominate R.

test/Analysis/LazyValueAnalysis/lvi-after-jumpthreading.ll
59 ↗(On Diff #95481)

I'm not sure if it is correct to say that %iv2.next is used in %loop -- a PHI node's use counts as a use at the end of the incoming block.

sanjoy requested changes to this revision.Apr 20 2017, 4:01 PM
This revision now requires changes to proceed.Apr 20 2017, 4:01 PM
anna added inline comments.Apr 21 2017, 10:42 AM
lib/Analysis/LazyValueInfo.cpp
1904 ↗(On Diff #95481)

If I does not dominate BB, we fail on an unrelated assert (because we reach the entry basic block, where the only values whose LVI can be calculated are arguments and values defined in the block). It actually boils down to the implicit assumption that we can't calculate getValueInBlock if I does not dominate BB.
I would think that we return undefined for the example you've above, rather than fail on the assert.

This is the same assertion failure for the test2.

I'll make this a stricter requirement, rather than depend on successors.

test/Analysis/LazyValueAnalysis/lvi-after-jumpthreading.ll
59 ↗(On Diff #95481)

Agreed. Phi-nodes need to be treated differently.

anna updated this revision to Diff 96399.Apr 24 2017, 8:04 AM
anna edited edge metadata.

Use dominator information to identify which blocks we can solve for.
Addressed review comments.

anna marked 2 inline comments as done.Apr 24 2017, 8:06 AM
anna added inline comments.
test/Analysis/LazyValueAnalysis/lvi-after-jumpthreading.ll
59 ↗(On Diff #95481)

Added the test back since PhiNode uses are handled separately (only consider phi uses that dominate the def of the value).

reames accepted this revision.May 30 2017, 4:23 PM

LGTM w/required changes.

lib/Analysis/LazyValueInfo.cpp
1871 ↗(On Diff #96399)

The const_casts looks concerning here. We should be able to walk all the function/arg stuff without them; at most we need to cast before invoking the LVI interface.

1901 ↗(On Diff #96399)

I'd print the unknown values too for ease of testing and consistency.

This revision was automatically updated to reflect the committed changes.
anna marked an inline comment as done.Jun 6 2017, 12:26 PM
anna marked an inline comment as done.