[PATCH] D64551: [X86] EltsFromConsecutiveLoads - support common source loads

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added inline comments.


================
Comment at: llvm/trunk/test/CodeGen/X86/load-partial.ll:86
 ; AVX:       # %bb.0:
-; AVX-NEXT:    vmovss {{.*#+}} xmm0 = mem[0],zero,zero,zero
-; AVX-NEXT:    vinsertps {{.*#+}} xmm0 = xmm0[0],mem[0],xmm0[2,3]
-; AVX-NEXT:    vinsertps {{.*#+}} xmm0 = xmm0[0,1],mem[0],xmm0[3]
+; AVX-NEXT:    vmovaps (%rdi), %xmm0
 ; AVX-NEXT:    retq
----------------
yubing wrote:
> RKSimon wrote:
> > yubing wrote:
> > > This is not correct, since we are moving 3 float numbers to %xmm0, according to IR, instead of 4 float.
> > > Before your patch, the testcase's CHECK is correct:
> > > ; AVX:       # %bb.0:
> > > ; AVX-NEXT:    vmovss  (%rdi), %xmm0           # xmm0 = mem[0],zero,zero,zero
> > > ; AVX-NEXT:    vinsertps       $16, 4(%rdi), %xmm0, %xmm0 # xmm0 = xmm0[0],mem[0],xmm0[2,3]
> > > ; AVX-NEXT:    vinsertps       $32, 8(%rdi), %xmm0, %xmm0 # xmm0 = xmm0[0,1],mem[0],xmm0[3]
> > > ; AVX-NEXT:    retq
> > The pointer is 16 byte dereferencable - loading all 4 floats is safe.
> Sorry, It seems I am not familiar with 'dereferencable'. Could you please explain it in detail?
> All I see is that moving only 3 float numbers to %xmm0, according to IR.
... moving 3 floats to %xmm, with 4'th channel being `undef`.
As per `dereferenceable` attribute, we can load 16 bytes here,
and since we are allowed to replace `undef` with anything,
we can just simply load the entire %xmm0.
So i'm not seeing an issue *here*. Can you explain what issue do you see?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64551