[PATCH] Compute known bits using invariants

Chandler Carruth chandlerc at gmail.com
Thu Jul 17 11:54:16 PDT 2014

Comment at: lib/Analysis/ValueTracking.cpp:444-454
@@ +443,13 @@
+static void findInvariantUsers(Value *V, SmallVector<Value *, 8> &Invs,
+                               const DataLayout *DL, const Query &Q,
+                               unsigned Depth = 0) {
+  // At depth 0 we're provided with the original value, at other depths, the
+  // possible opcodes are restricted to limit the cost of the search.
+  // For example:
+  // 0  V           V             V           V
+  // 1  ptrtoint    icmp          ptrtoint    and
+  // 2  icmp        invariant     and         icmp
+  // 3  invariant                 icmp        invariant
+  // 4                            invariant
This kind of logic is the only part of the current invariant approach that really made me want to structure it more as an analysis pass. I feel like this is too likely to end up being a set of magical sequences that are the only ways we recognize invariants.

What do you think about separating out the logic for computing relevant invariant sets and using them completely? I'm wondering if we should essentially have an invariant "analysis" which constitutes the interface that transformations can query. This might include:

- Binding the context and dominance queries away from the user code behind a single API.
- Supporting use cases where we do an expensive search of invariants first, and then query those invariants repeatedly. I'm specifically thinking we might reverse the pattern and build from the roots up.


More information about the llvm-commits mailing list