This patch adds a known-bits cache for value tracking, and uses it from InstCombine. This works, even though the known-bits computation retains its depth cutoff, because InstCombine uses a (generally) top-down walking strategy, so the known-bits of a value's operands are generally caches when the known bits of the value are requested.
The advantages of doing this are (potentially):
- Limit the expense of computing known bits (which currently does a lot of walking), hopefully making InstCombine cheaper.
- Effectively provide a known-bits computation of unlimited depth (thus making the optimizer more powerful).
If an assumption contributes to the known bits, then the result cannot be cached (because the cache is not context dependent, but assumptions are context dependent).
This is a work-in-progress (I initially put this together last November, and just rebased it now in light of current discussions). It has one problem I know about: We'd need to invalidate the cached known bits of a value when we remove its nsw/nuw/etc. flags, and this is currently not done. Removing these flags causes changes, potentially, to the known bits of that value and also all of its users. This is the cause of at least some of the regression-test failures:
Failing Tests (4): LLVM :: Transforms/InstCombine/demand_shrink_nsw.ll LLVM :: Transforms/InstCombine/icmp.ll LLVM :: Transforms/InstCombine/select.ll LLVM :: Transforms/InstCombine/sext.ll
I'm posting this in its current state to make it easier to experiment with the relative costs/benefits of caching to the performance of InstCombine.