[llvm-dev] ShuffleKind SK_ExtractSubvector

[Friedman, Eli via llvm-dev]

On 2/8/2017 11:00 PM, Jonas Paulsson wrote:
>
>
> On 2017-02-08 20:10, Friedman, Eli wrote:
>> On 2/8/2017 6:35 AM, Jonas Paulsson via llvm-dev wrote:
>>> 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

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project