[PATCH] D63512: [X86] Add DAG combine to turn (vzmovl (insert_subvector undef, X, 0)) into (insert_subvector allzeros, (vzmovl X), 0)

[Craig Topper via Phabricator via llvm-commits]

craig.topper marked 3 inline comments as done.
craig.topper added inline comments.


================
Comment at: llvm/test/CodeGen/X86/avx-load-store.ll:243
 ; CHECK_O0-NEXT:    vmovd %eax, %xmm0
+; CHECK_O0-NEXT:    vmovdqa %xmm0, %xmm0
 ; CHECK_O0-NEXT:    vmovaps %xmm0, %xmm1
----------------
This is because we emit a SUBREG_TO_REG+MOV for insert_subvector(zero) and our post processing peephole that removes the MOV when possible doesn't run at -O0.


================
Comment at: llvm/test/CodeGen/X86/vec_extract-avx.ll:147
 ; X32-NEXT:    movl {{[0-9]+}}(%esp), %ecx
-; X32-NEXT:    vmovups (%ecx), %xmm0
-; X32-NEXT:    vxorps %xmm1, %xmm1, %xmm1
-; X32-NEXT:    vblendps {{.*#+}} xmm0 = xmm0[0,1],xmm1[2,3]
+; X32-NEXT:    vmovsd {{.*#+}} xmm0 = mem[0],zero
 ; X32-NEXT:    vmovaps %ymm0, (%eax)
----------------
This is due to some inconsistencies between our handling of v4i64 vzmovl and v2i64 vzmovl. You'll see this same test case was changed by D63373 in a different way. The really weird thing here is that we're reducing the size of a load in an isel pattern. Which isn't good since we don't check if its volatile. We should remove these kinds of isel patterns and do something in DAG combine to move towards vzload.


================
Comment at: llvm/test/CodeGen/X86/vector-shuffle-256-v4.ll:1507
 ; ALL:       # %bb.0:
-; ALL-NEXT:    # kill: def $xmm0 killed $xmm0 def $ymm0
-; ALL-NEXT:    vxorps %xmm1, %xmm1, %xmm1
-; ALL-NEXT:    vblendps {{.*#+}} xmm0 = xmm0[0,1],xmm1[2,3]
+; ALL-NEXT:    vmovq {{.*#+}} xmm0 = xmm0[0],zero
 ; ALL-NEXT:    retq
----------------
This is also due to inconsistencies between v4f64 and v2f64 vzmovl handling. We also generate this same code after D63373


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

https://reviews.llvm.org/D63512