[PATCH] D79886: [DAGCombiner] try to move splat after binop with splat constant

[Sanjay Patel via Phabricator via llvm-commits]

spatel marked an inline comment as done.
spatel added inline comments.


================
Comment at: llvm/test/CodeGen/X86/vector-rotate-128.ll:854
 ; SSE2:       # %bb.0:
-; SSE2-NEXT:    pshuflw {{.*#+}} xmm1 = xmm1[0,0,2,3,4,5,6,7]
-; SSE2-NEXT:    pshufd {{.*#+}} xmm1 = xmm1[0,0,0,0]
+; SSE2-NEXT:    movl $65535, %eax # imm = 0xFFFF
+; SSE2-NEXT:    movd %eax, %xmm2
----------------
spatel wrote:
> craig.topper wrote:
> > Something weird happened here I think. We appear to be loading a constant as an immediate and moving it into a vector. Then we AND it with something that was just ANDed with a constant pool. Could the two ANDs using a single constant pool?
> I think the root cause is that we don't have a combine for:
> ZERO_EXTEND_VECTOR_INREG --> BITCAST 
> ...if we know all of the high bits are already zero.
> 
> That's visible in existing tests - for example in the SSE41 or AVX1 output for this test, we don't need to pand+pmovzxwq.
> 
> I have a draft of that patch, and it causes a massive amount of test diffs...taking a look now.
Oh wait...I got my vector elements mixed up. This is just a bizarre build vector legalization:

```
Legalizing: t83: v8i16 = BUILD_VECTOR Constant:i16<-1>, Constant:i16<0>, Constant:i16<0>, Constant:i16<0>, undef:i16, undef:i16, undef:i16, undef:i16
Trying custom legalization
Creating constant: t84: i32 = Constant<65535>
Creating new node: t85: v4i32 = scalar_to_vector Constant:i32<65535>
Creating constant: t86: i32 = Constant<0>
Creating new node: t87: v4i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<0>, Constant:i32<0>, Constant:i32<0>
Creating new node: t88: v4i32 = vector_shuffle<4,1,2,3> t87, t85
Creating new node: t89: v8i16 = bitcast t88

```


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

https://reviews.llvm.org/D79886