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

[Bing Yu via Phabricator via llvm-commits]

yubing 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
----------------
lebedev.ri wrote:
> 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?
You're right. Now I get your point.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64551