[PATCH] D140796: [ValueTracking] Improve ComputeNumSignBits to handle Trunc

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 2 01:45:00 PST 2023


nikic added inline comments.


================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:3334
+
       break;
+    }
----------------
resistor wrote:
> nikic wrote:
> > return 1 here, we don't want to fall through to computeKnownBits (the ComptueNumSignBits will have already used it if possible).
> I don't think that's the case? We invoked `ComputeNumSignBits` on the input to the trunc, so we haven't yet had an opportunity to use `computeKnownBits` results for the output.
Hm, I guess you are right. If the truncated part doesn't have sign bits and the part directly following has more than one known zero/one bits, then the computeKnownBits() call is still useful.

Do we already have a test that fails if it is removed?


================
Comment at: llvm/test/Transforms/InstCombine/vector-trunc.ll:24
+;
+  %2 = ashr <4 x i32> %0, <i32 8, i32 8, i32 8, i32 8>
+  %3 = trunc <4 x i32> %2 to <4 x i16>
----------------
It would be slightly better to test the values where the behavior flips, so I guess that should be a shift by 17 above and by 16 here.


================
Comment at: llvm/test/Transforms/InstCombine/vector-trunc.ll:41
+  ret <4 x i16> %4
+}
----------------
Am I missing something, or is this test the same as the previous one?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140796



More information about the llvm-commits mailing list