[PATCH] D112276: [InstCombine] Fold `(c & ~(a | b)) | (b & ~(a | c))` to `~a & (b ^ c)`

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

In D112276#3085648 <https://reviews.llvm.org/D112276#3085648>, @rampitec wrote:

> Added more tests:
>
> - or_not_and_commute4 - missing commute test. Note, I believe the rest of the commutes are covered because LHS and RHS are simmetrical. It is only a matter of what variables to call A, B and C, the logic is the same.

If LHS and RHS are symmetric, then do we really need the second "match(Op1" clause in the code?

> - or_not_and_extra_or_use1/2 - tests for mutiple uses of either of two OR opcodes. Combine is still allowed since it is still less code: 4 instructions vs 7. Tests for mutiple uses of either AND and NOT are already precommited.

I agree that we don't need one-use checks on everything. In fact, the match seems overspecified for that, so it might be limiting the optimization power in the motivating source. 
The way I view this is that we are creating 3 instructions, so as long as any 2 of the original intermediate values has one use, then the transform is desirable (because we're eliminating those 2 intermediate values + replacing the final `or` and reducing use counts of other values along the way).

@lebedev.ri - do you have any suggestions for how to specify that constraint in the code?



================
Comment at: llvm/test/Transforms/InstCombine/and-xor-or.ll:798
-; CHECK-NEXT:    [[AND1:%.*]] = and i32 [[C]], [[NOT1]]
-; CHECK-NEXT:    [[OR2:%.*]] = or i32 [[C]], [[A]]
-; CHECK-NEXT:    [[NOT2:%.*]] = xor i32 [[OR2]], -1
----------------
By making `%c` a binop, it stuck as operand 0 for `%and1`, but that also commuted this `or`. Make `%a` a binop as well, so that doesn't change under us?

I realize this is tedious, but I think there really are at least 8 potential commuted variants.


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

https://reviews.llvm.org/D112276