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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> Not sure about this, would we be better off attempting a SHUFFLE(BUILD_VECTOR(), BUILD_VECTOR()) -> SHUFFLE(BUILD_VECTOR(), UNDEF) combine replacing repeated insertions with shuffles?

This doesn't reliably produce better code; for example, see https://llvm.org/bugs/show_bug.cgi?id=31301.  The particular shuffle written by the user is cheaper than anything we're realistically going to produce from `SHUFFLE(BUILD_VECTOR(), UNDEF)` unless we add a special case specifically for `ZIP(splat, splat)`, and I don't have the time to write code to special-case every possible permutation of `SHUFFLE(splat, splat)`/`SHUFFLE(SHUFFLE(splat, splat), SHUFFLE(splat, splat))`/etc. for every target supported by LLVM.



================
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
----------------
mkuper wrote:
> 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.
(Phabricator won't let me delete this...)


Repository:
  rL LLVM

https://reviews.llvm.org/D27787