[PATCH] D28747: [X86] Don't create VBROADCAST nodes with 256-bit or 512-bit input types
Craig Topper via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun Jan 15 12:43:43 PST 2017
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
More information about the llvm-commits
mailing list