[PATCH] D27787: Don't combine a shuffle of two BUILD_VECTORs in general.

[Michael Kuperstein via Phabricator via llvm-commits]

mkuper added inline comments.


================
Comment at: test/CodeGen/ARM/vzip.ll:270
 entry:
   ; CHECK-LABEL: vzip_lower_shufflemask_undef
   ; CHECK: vzip
----------------
efriedma wrote:
> mkuper wrote:
> > Regenerate this with the update script?
> There is no update script for ARM, as far as I know; it's possible I should spend some time writing one.
Right, forgot, I'm too used to x86, sorry. :-)


================
Comment at: test/CodeGen/X86/mmx-bitcast.ll:83
 ; CHECK-NEXT:    punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
-; CHECK-NEXT:    movd %xmm1, %rax
+; CHECK-NEXT:    pshufd {{.*#+}} xmm0 = xmm1[0,1,1,3]
+; CHECK-NEXT:    movd %xmm0, %rax
----------------
efriedma wrote:
> mkuper wrote:
> > This looks like a common enough pattern that I'm not excited about regressing it at the expense of the "zip" example.
> Mmm... maybe.  I would appreciate suggestions.
I don't really have good ones.

My knee-jerk reaction is "do the (simplifying!) combine, and improve build_vector lowering". I guess, in general, that would require looking at the BUILD_VECTOR and trying to find the best way to split it into the best sequence of BUILD_VECTORs and target shuffles. After all, there's nothing guaranteeing the pre-combine BUILD_VECTORs were optimal in any way. What if you're shuffling two BUILD_VECTORs that are splats of the same value?

But this all sounds a bit scary.


Repository:
  rL LLVM

https://reviews.llvm.org/D27787