[PATCH] D115755: [InstSimplify] Fold logic And to Zero

[Mehrnoosh Heidarpour via Phabricator via llvm-commits]

MehrHeidar marked 2 inline comments as done.
MehrHeidar added inline comments.


================
Comment at: llvm/lib/Analysis/InstructionSimplify.cpp:2180
+    return Constant::getNullValue(Op0->getType());
+  // ((A | B) ^ B ) & ((A | B) ^ A) --> 0
+  if (match(Op0, m_c_Xor(m_c_Or(m_Value(X), m_Value(Y)), m_Deferred(Y))) &&
----------------
rampitec wrote:
> MehrHeidar wrote:
> > rampitec wrote:
> > > MehrHeidar wrote:
> > > > rampitec wrote:
> > > > > You could use 'm_CombineOr' for the LHS to select either deferred X or deferred Y. Then you do not need second expression.
> > > > I replaced the comments and changed the usage of A/B with X/Y.
> > > > Also, I tried to use the idea for usage of `m_CombineOr` to remove the second expression.
> > > Second match shall not use m_CombineOr. Now you would incorrectly match `((X | Y) ^ X ) & ((X | Y) ^ X)`. Speaking of which it deserves a negative test.
> > If I don't put the `m_CombineOr` on the second match, we won't be able to catch all commutes. I added a negative test now to see it won't incorrectly match your example.
> > 
> > I am not so confident with the current code too and prefer my first version of this patch. What do you think @rampitec ?
> > 
> m_CombineOr is not about commute. At the point of second match you already know your X and Y exactly.
As I mentioned before, not using `m_CombineOr` doesn't allow me to catch all versions, so I reverted back to first version that I had.


================
Comment at: llvm/test/Transforms/InstSimplify/and.ll:191
+; CHECK-LABEL: @or_xor_commute4(
+; CHECK-NEXT:    [[OR:%.*]] = or <2 x i64> [[X:%.*]], [[Y:%.*]]
+; CHECK-NEXT:    [[XOR2:%.*]] = xor <2 x i64> [[OR]], [[X]]
----------------
rampitec wrote:
> And in fact the test does not catch it. I think 'and' was simply dropped earlier. Maybe a duplicated 'or' will expose it or maybe not.
Agree! I only added the previous test for the sake of your previous comment, I was not going to commit that=)
Thank you! Changed the code so it's not a concern anymore.


================
Comment at: llvm/test/Transforms/InstSimplify/and.ll:168
   %or = or i71 %x, %y
   %xor1 = xor i71 %x, %or
   %xor2 = xor i71 %y, %or
----------------
rampitec wrote:
> MehrHeidar wrote:
> > MehrHeidar wrote:
> > > rampitec wrote:
> > > > spatel wrote:
> > > > > rampitec wrote:
> > > > > > 'or' is more complex than the argument, the xor will be commuted.
> > > > > > See InstCombiner::getComplexity() for the details. Search for "thwart complexity-based canonicalization" in the llvm/test/Transforms/InstCombine directory for test coverage that works around it.
> > > > > This is instsimplify, so we don't have to worry about the pass itself altering the input (this is shown in the baseline CHECK lines).
> > > > Ok, thanks.
> > > I think the test coverage looks fine, based on @spatel  comment,
> > > 
> > > 
> > > 
> > > > Quoted Text
> > > 
> > > 
> > > Right?
> > I think according to the comment the test coverage is fine.
> > > This is instsimplify, so we don't have to worry about the pass itself altering the input (this is shown in the baseline CHECK lines).
> > 
> > Right?
> Yes, but there are 2 more commutes: `(a ^ (a | b)) & ((a | b) ^ b)` and `((a | b) ^ b) & (a ^ (a | b))`
Right, thanks! 
Added two more commutes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115755