[PATCH] D82602: [SelectionDAG] don't split branch on logic-of-vector-compares

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 26 10:55:46 PDT 2020


spatel added a comment.

In D82602#2117150 <https://reviews.llvm.org/D82602#2117150>, @uweigand wrote:

> In D82602#2116747 <https://reviews.llvm.org/D82602#2116747>, @spatel wrote:
>
> > 2. I missed a SystemZ test change in the earlier draft; adding SystemZ reviewers to confirm if that's an improvement.
>
>
> Interesting.   The compiler now completely optimizes out all operations on one of the two vector lanes, apparently because it recognizes their value is constant and computable at compile time.  So that's an improvement (even though not one this test case was expecting to happen ...).
>
> On the other hand, in the operations on the remaining lane, it seems the compiler is now no longer able to perform the known-bits optimization that this test is actually written for -- see the comment that says we should optimize out a redundant AND to get a compare instead of a TM (test-under-mask), but the code now actually does contain a TM (tmll).  That seems a regression at first glance.


Thanks. I can't tell if there's some generic transform that would help or if something target-specific is missing.
We have this after type-legalization:

        t50: v4i32 = BUILD_VECTOR undef:i32, t32, undef:i32, undef:i32
      t51: v2i64 = bitcast t50
      t30: v2i64 = BUILD_VECTOR Constant:i64<1>, Constant:i64<1>
    t36: v2i64 = xor t51, t30
  t45: v4i32 = bitcast t36

Would converting the xor to v4i32 help? computeKnownBits probably has problems looking through bitcasts.


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

https://reviews.llvm.org/D82602





More information about the llvm-commits mailing list