[PATCH] D28747: [X86] Don't create VBROADCAST nodes with 256-bit or 512-bit input types

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

What became of previous conversations about splitting the opcodes?



================
Comment at: lib/Target/X86/X86ISelLowering.cpp:5488
     // We only decode broadcasts of same-sized vectors at the moment.
-    if (N->getOperand(0).getValueType() == VT) {
+    if (N->getOperand(0).getValueType() == VT || FromExtract) {
       DecodeVectorBroadcast(VT, Mask);
----------------
RKSimon wrote:
> I've got the horrid feeling this will cause problems for combineX86ShufflesRecursively which decodes shuffles but at the moment asserts if the inputs are not the same size as the shuffle result itself.
Does the fact that I put an node with the matching type into the Ops vector not help?


================
Comment at: test/CodeGen/X86/widened-broadcast.ll:128
 ; AVX1-NEXT:    vinsertf128 $1, %xmm0, %ymm0, %ymm0
 ; AVX1-NEXT:    retq
 ;
----------------
RKSimon wrote:
> Any idea why AVX1 fails?
Probably something to do with the lowering as broadcast only supporting integer types with AVX2. But that's just a guess.


https://reviews.llvm.org/D28747