[PATCH] D94866: [ValueTracking] Strengthen impliesPoison reasoning

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D94866#2504011 <https://reviews.llvm.org/D94866#2504011>, @aqjune wrote:

> Okay, I agree that this is more general.
> I was cautious about possible compile time degradation - do you have a number for this?

Compile-time results (on top of flipping the select optimization flag, otherwise it would not get called): https://llvm-compile-time-tracker.com/compare.php?from=0c9e135ecde32b57393fb502cc45f90c2a17346d&to=3d7dcc78542627d6440613327f21d177bcdf6f00&stat=instructions There does not seem to be any impact above noise.



================
Comment at: unittests/Analysis/ValueTrackingTest.cpp:783
+                "  %M2 = and i32 %x, 7\n"
+                "  %A2 = icmp eq i32 %x, 1\n"
+                "  %M = and i32 %x, 15\n"
----------------
aqjune wrote:
> Maybe `icmp eq i32 %M2, 1` here? (similarly below)
Yes, this test didn't make sense...


================
Comment at: unittests/Analysis/ValueTrackingTest.cpp:790
+}
+
 TEST_F(ValueTrackingTest, ComputeNumSignBits_Shuffle_Pointers) {
----------------
aqjune wrote:
> Shall we have one more example that has EXPECT_FALSE because ValAssumedPoison was e.g. `icmp eq %x, %z` where z wasn't used by A?
I think this case is checked by the existing impliesPoisonTest_ICmpUnknown test. It uses `icmp eq i32 %x, %y` and `icmp eq i32 %x, 1`.


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

https://reviews.llvm.org/D94866