[InstCombine] Replace call to haveNoCommonBitsSet in visitXor with just the special case that doesn't use computeKnownBits.

[craig.topper]

Summary

computeKnownBits is expensive. The cases that would be detected by the computeKnownBits portion of haveNoCommonBitsSet were already handled by the earlier call to SimplifyDemandedInstructionBits.

[lebedev.ri]

This is a NFC, right?

I suppose it makes sense. I kinda hoped inlining would have taken care of it.
There may be a similar case in the visitAdd().

lib/Transforms/InstCombine/InstCombineAndOrXor.cpp

2513

s/it/is/

2517–2520

Here this could be

if (match(&I, m_c_Xor(m_c_And(m_Not(m_Value(M)), m_Value()), 
                      m_c_And(m_Deferred(M), m_Value()))))

[craig.topper]

We don't currently turn Add into Or inside SimplifyDemandedBits so visitAdd doesn't have this issue. I'm a little skeptical that we should be aggressively turning adds into ors. I plan to start an llvm-dev thread on that.

I believe this is NFC based on my understanding of SimplifyDemandedInstructionBits and haveNoCommonBitSet.

lib/Transforms/InstCombine/InstCombineAndOrXor.cpp

Instruction *InstCombiner::visitXor(BinaryOperator &I) {
   // See if we can simplify any instructions used by the instruction whose sole
   // purpose is to compute bits we don't care about.
   if (SimplifyDemandedInstructionBits(I))
     return &I;
 
   if (Value *V = SimplifyBSwap(I, Builder))
     return replaceInstUsesWith(I, V);
 
-  // A^B --> A|B iff A and B have no bits set in common.
   Value *Op0 = I.getOperand(0), *Op1 = I.getOperand(1);
-  if (haveNoCommonBitsSet(Op0, Op1, DL, &AC, &I, &DT))
+
+  // Fold (X & M) ^ (Y & ~M) -> (X & M) | (Y & ~M)
+  // This it a special case in haveNoCommonBitsSet, but the commputeKnownBits
+  // calls in there are unnecessary as SimplifyDemandedInstructionBits should
+  // have already taken care of those cases.
+  Value *M;
+  if ((match(Op0, m_c_And(m_Not(m_Value(M)), m_Value())) &&
+       match(Op1, m_c_And(m_Specific(M), m_Value()))) ||
+      (match(Op1, m_c_And(m_Not(m_Value(M)), m_Value())) &&
+       match(Op0, m_c_And(m_Specific(M), m_Value()))))
     return BinaryOperator::CreateOr(Op0, Op1);
 
   // Apply DeMorgan's Law for 'nand' / 'nor' logic with an inverted operand.
   Value *X, *Y;
 
   // We must eliminate the and/or (one-use) for these transforms to not increase
   // the instruction count.
   // ~(~X & Y) --> (X | ~Y)