ShuffleKind SK_ExtractSubvector

Hi,

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?

/Jonas

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 convenient.

-Eli

I suppose it would make sense to follow the ISD::EXTRACT_SUBVECTOR rules, then.

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.

/Jonas

Hi,

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 convenient.

I suppose it would make sense to follow the ISD::EXTRACT_SUBVECTOR rules, then.

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.

Some targets have other special-cases which are important; for example, extracting the high half of a 128-bit vector on ARM is free.

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.

It's not always a no-op because not all targets widen small vectors; we promote to a wider integer type instead in some cases.

-Eli