Correctly identify the following pattern, which has no common bits: (X & ~M) op (Y & M).
Added ll test for X86 Target.
prior to the patch, the ir included an or instruction:
; CHECK-NEXT: andl %esi, %edx ; CHECK-NEXT: notl %esi ; CHECK-NEXT: andl %edi, %esi ; CHECK-NEXT: orl %edx, %esi ; CHECK-NEXT: leal 1(%rsi), %eax
After the patch, the or instruction can be combined into an add, since the operands have no common bits.
Maybe better to pull this into haveNoCommonBitsSet as lambda?
You need to try and ensure we have test coverage for all of these permutations.
Once you have more test coverage, we should add these tests to trunk with current codegen so you can rebase and the patch shows the diff.
Do we expect all vector types/targets to bypass this in some way? If yes, it's worth adding a comment to the patch description and/or code. If no, can we find a test that shows an asm difference?
I mean are there TLI hooks (for example hasAndNot) or other transforms that will trigger before or after this such that vector instructions are never affected?
It sounds like the answer is 'no'. Therefore, yes we should have another lit test with vector types, so we can see the difference from this patch.