This is an archive of the discontinued LLVM Phabricator instance.

[LVI] Clarify invariants, common code, and fix latent bugs
AbandonedPublic

Authored by reames on Nov 2 2015, 3:50 PM.

Details

Summary

This patch includes a couple of small changes needed for a follow on patch. One them fixes a latent bug (which I believe is unreachable today).

Changes are:

  1. Ensure that calling getValueInBlock with a constant works. It's trivial, but there's nothing preventing this getting called in the outer layers. Additionally, we've been apparently re-querying the outermost block on each access. This is a waste of compile time and (hopefully) will produce the same result as using the previously cached result.
  2. Use the full power of the getValueInBlock interface for getValueAt when the query instruction is at the end of a block. I don't know of a test case which clearly illustrates this difference, but in principal, we may be able to remove a few extra comparisons after this change. The main reason for this is to better test existing code paths.
  3. Fix a bug exposed by (2) where we weren't actually using the range metadata results within the getValueInBlock solving.

Diff Detail

Event Timeline

reames updated this revision to Diff 38996.Nov 2 2015, 3:50 PM
reames retitled this revision from to [LVI] Clarify invariants, common code, and fix latent bugs.
reames updated this object.
reames added reviewers: hfinkel, sanjoy.
reames added a subscriber: llvm-commits.
sanjoy edited edge metadata.Nov 13 2015, 12:34 PM

Some comments inline. Given that I'm not familiar with LVI, take the comments with a grain of salt.

lib/Analysis/LazyValueInfo.cpp
578

I think the same logic can be better stated by having Res be a Optional<LVILatticeVal> instead of LVILatticeVal. Using the undefined state this way is confusing as I'd normally assume a value to be undefined to mean that the code that uses it is dead.

1041

Does this mean the assert in pushBlockValue can be strengthened to assert(!hasBlockValue(V, BB)) (instead of just checking for a Constant)?

1061

If getValueInBlock computes the result at the end of BB, is CxtI a redundant parameter?

test/Transforms/CorrelatedValuePropagation/basic.ll
227

we can use assume facts to prove things about terminators

So CVP can simplify the %res use in the branch? If so, can you please add a CHECK line checking for the same?

sanjoy requested changes to this revision.Nov 13 2015, 12:34 PM
sanjoy edited edge metadata.
This revision now requires changes to proceed.Nov 13 2015, 12:34 PM
reames abandoned this revision.Aug 24 2018, 2:48 PM