[PATCH] D46814: [InstCombine] Canonicalize (not fold!) unfolded masked merge pattern.

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D46814#1099660, @spatel wrote:

> I think we're close on the DAG safety belt (giving @RKSimon some time to look at the x86 tests I think).
>
> ...so hold off on this until that lands?


Sure, can do!

> Then we'd just convert directly to the xor sequence?

Yep, the plan is then to extend the matcher from

  if (match(&I,
            m_c_And(m_OneUse(m_c_Or(m_Value(X), m_CombineAnd(m_Not(m_Value(M)),
                                                             m_Value(NotM)))),
                    m_OneUse(m_c_Or(m_Value(Y), m_Deferred(M)))))) {

to basically

  if (match(&I,
            m_c_And(m_OneUse(m_c_Or(m_Value(X), m_CombineAnd(m_Not(m_Value(M)),
                                                             m_Value(NotM)))),
                    m_OneUse(m_c_Or(m_Value(Y), m_Deferred(M))))) ||
      match(&I,
                  m_c_Or(m_OneUse(m_c_And(m_Value(Y), m_CombineAnd(m_Not(m_Value(M)),
                                                                   m_Value(NotM)))),
                         m_OneUse(m_c_And(m_Value(X), m_Deferred(M))))) || ) {

so they both will get folded.

> But I am curious - did you find this pattern in real code? I've never seen masked merge using or/nor before.

In real high-level code, i agree i did not see it.
Which makes sense, since `nor` is not too widely available.

The most important point here is that i'm trying to have the full coverage,
since this is essentially the same pattern, just written differently.
And since it is this rare, it's possible that it is less properly covered by tests and transforms..

But additionally, if we canonicalize the `(x | ~C) & (y | C)` pattern,
then the `haveNoCommonBitsSet()` will be more likely to work,
since i'm not quite sure how it handles this odd pattern.


Repository:
  rL LLVM

https://reviews.llvm.org/D46814