[llvm-dev] ShuffleKind SK_ExtractSubvector
Jonas Paulsson via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 8 23:00:53 PST 2017
On 2017-02-08 20:10, Friedman, Eli wrote:
> On 2/8/2017 6:35 AM, Jonas Paulsson via llvm-dev wrote:
>> I am a little unsure about the semantics of the ShuffleKind
>> SK_ExtractSubvector. It seems a subvector is to be extracted,
>> starting from a given index of a given subtype.
>> First of all, if index 0 is passed, I suppose this would mean a noop?
>> But what about calls like the one made of LoopVectorizer for
>> Instruction::PHI in getInstructionCost():
>> return TTI.getShuffleCost(TargetTransformInfo::SK_ExtractSubvector,
>> VectorTy, VF - 1, VectorTy);
>> Here the highest index is passed, which doesn't make sense to me. Nor
>> does it make sense to pass the the same VectorTy in both parameters.
>> In BBVectorize, start index 0 is passed in one place, but then in
>> another place start index of 'VF' is passed, which should even be
>> outside possible indexes, or?
>> I guess this is confusing since there are those extra parameters and
>> everything, but in the end it seems to me there is no code anywhere
>> checking this particular ShuffleKind, or?
> I think the intent is to match the rules for EXTRACT_SUBVECTOR in isel
> (hence the name). But, as you've noted, no in-tree targets are
> actually using it, so we can redefine it to use whatever definition is
I suppose it would make sense to follow the ISD::EXTRACT_SUBVECTOR
The indexes are passed currently in three places, and they are 0, VF -
1, and VF, where certainly the last wouldn't be legal, and the second
would hardly make sense. I am not sure what the context is in the three
cases this is used, but I could imagine that passing VF or VF - 1 should
mean "the highest valid index" of the subvector type.
It seems the line in LoopVectorizer, which extracts a subvector of same
type as the original type should be fixed, but I am not sure exactly how.
On SystemZ, extracting from index 0 is a noop. If a vector type gets
split is used as input, and the higher part is extracted, that should
also be a noop.
I don't know if this is true for all targets, but if it was this could
be handled in common code.
More information about the llvm-dev