aqjune added a comment.
(renaming variables for readability)
%a = select i1 %s, i1 undef, i1 %t
%b = xor i1 %s, 1
%c = and i1 %a, %b
This series of reasoning happened from a single SimplifyAndInst call:
c = a & (s ^ 1)
= (a & s) ^ (a & 1) ; ExpandBinOp
= ((select s, undef, t) & s) ^ a
= (select s, (undef & s), (t & s)) ^ a ; ThreadBinOpOverSelect
= (select s, (undef & s), false) ^ a ; since s = (x == y), t = (x < y)
= (select s, false, false) ^ a ; choose undef to be false
= a
= select s, undef, t
In general, distributing `a` into operands of xor (second line) isn't sound
because it increases the number of uses of `a`. We don't want to totally
disable the simplification, however.
If InstSimplify never increases the number of uses in the end, we have an
alternative solution: tracking to which value undef is folded.
Whenever an undef value is chosen to be a concrete value, the decision should
be remembered, so the copied undefs won't be folded into different values.
In case of InstSimplify, we can identify individual undefs by Use, since
InstSimplify won't do any transformation inside.
This means SimplifyXXX needs to return two things: the simplified value & the
undef cache. Since InstSimplify isn't designed to do transformation directly,
other optimizations like InstCombine should perform the final change.
Does this solution make sense? Then, I can prepare a patch for this.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D83360/new/
https://reviews.llvm.org/D83360
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
