search for: shufflemask

...teNo != InputByteNo)       return true;   } Note that 'then' and 'else' are the same. It can be a problem or can not. ---- lib/Target/X86/InstPrinter/X86InstComments.cpp:208   case X86::VPERMILPSri:     DecodeVPERMILPSMask(4, MI->getOperand(2).getImm(),                         ShuffleMask);     Src1Name = getRegName(MI->getOperand(0).getReg());   case X86::VPERMILPSYri:     DecodeVPERMILPSMask(8, MI->getOperand(2).getImm(),                         ShuffleMask);     Src1Name = getRegName(MI->getOperand(0).getReg()); The 'Src1Name' variable is assigned values twice s...

...are the same. It can be a problem or can not. I've CC'd Chris since he wrote this code. > > ---- > > lib/Target/X86/InstPrinter/X86InstComments.cpp:208 > case X86::VPERMILPSri: > DecodeVPERMILPSMask(4, MI->getOperand(2).getImm(), > ShuffleMask); > Src1Name = getRegName(MI->getOperand(0).getReg()); > case X86::VPERMILPSYri: > DecodeVPERMILPSMask(8, MI->getOperand(2).getImm(), > ShuffleMask); > Src1Name = getRegName(MI->getOperand(0).getReg()); > > The 'Src1Name...

...or unsupported fixed-length shuffles. But the vectorizer would probably avoid generating unsupported shuffles, so it's unlikely to come up in practice.) In C++, I expect to represent this list as an enum, and then wrap up the entire description of a fixed or scalable shuffle into a class "ShuffleMask". This would allow checking whether an operation matches one of the above patterns, and can be converted to the existing ArrayRef<int> for fixed shuffles. ShuffleVectorInst::getShuffleMask would then return a ShuffleMask, I think. Then we could add an alternate API getFixedShuffleMask(...

...v64i1 vectors. We've got some preliminary notes here: http://parabix.costar.sfu.ca/wiki/BitShuffle Since we're quite new at this, I have some questions about strategy. (1) First, it seems that legalizing v32i1 and v64i1 types for x86 would make sense. This will allow us to retain the shufflemasks involving these vector types into code generation. (2) To legalize these types, we need to support all the vector operations. This involves implementing all of the IR operations on these vector types. For most of these it seems that simple substitutions suffice. Adding two 32vi1 vecto...

...we just can't represent the shuffle masks the same way. And I think if we do end up changing the representation of scalable shufflevectors later, we'll be able to autoupgrade the existing ones. I think I can keep the initial patch relatively small if we wrap the abstract notion of a "ShuffleMask", which is either a fixed shuffle or a named scalable shuffle, in a C++ class. And then we can let optimizations that expect fixed shuffles just convert that to the expected ArrayRef<int>. > Relatedly, how do you foresee canonicalization (in instcombine and inst > selection) work...

> -----Original Message----- > From: Chris Lattner <clattner at nondot.org> > Sent: Friday, February 7, 2020 3:00 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC] Extending shufflevector for vscale vectors > (SVE etc.) > > > On Feb 7, 2020, at 12:39 PM, Eli Friedman