[PATCH] D83360: [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X

Juneyoung Lee via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun Jul 12 20:23:55 PDT 2020


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





More information about the cfe-commits mailing list