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

Michael Kuperstein via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 15 09:12:21 PST 2016

mkuper added inline comments.

Comment at: test/CodeGen/ARM/vzip.ll:270
   ; 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.



More information about the llvm-commits mailing list