[PATCH] D86364: [ValueTracking] Interpret GEPs as a series of adds multiplied by the related scaling factor

[Nikita Popov via Phabricator via llvm-commits]

nikic requested changes to this revision.
nikic added a comment.
This revision now requires changes to proceed.

At least in the current implementation, the compile-time impact of this change is too large: http://llvm-compile-time-tracker.com/compare.php?from=12edd4b36475170d445ac93da34e4883f23a8361&to=1b942d71a1d7e7e55c91a2240eaaba617cc26d5a&stat=instructions

Possibly adding the early exit on unknown bits will help.



================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:1461
+    // True if we track all the bits of the address.
+    bool TrackAddr = true;
+
----------------
I don't understand the purpose of this variable and why we track both the precise known bits *and* the trailing zeros. In the one place that sets TrackAddr to false, can't you set the known bits to unknown?



================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:1470
     for (unsigned i = 1, e = I->getNumOperands(); i != e; ++i, ++GTI) {
-      // TrailZ can only become smaller, short-circuit if we hit zero.
-      if (TrailZ == 0)
+      if (TrailZ == 0 && !TrackAddr)
         break;
----------------
This should early exit if the AddrKnownBits are unknown, which would be the equivalent of the TrailZ==0 check.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86364/new/

https://reviews.llvm.org/D86364