[llvm-commits] Patch: Widening in LegalizeType

[Mon Ping Wang]

Hi Duncan,

On Nov 21, 2008, at 7:03 PM, Duncan Sands wrote:

> Hi Mon Ping,
>
>> Given that for any given type, it should be clear if that type is
>> legal or should be promoted, expanded, or widened, it make sense to
>> have only one function for this.  The only difference in
>> getWidenVectorType is that the function is virtual to allow a client
>> to decide that for certain vectors, though a legal type exist, that  
>> it
>> should not widen to that type because it might be cheaper to  
>> scalarize
>> it.  There is no reason that getTypeToTransform can't do the same
>> thing if certain target wants to override the default.  Today,  
>> without
>> any firm data, the difference between X86 and the default is so
>> slight, I'm inclined to have one function and add the virtual one  
>> when
>> we see a need.
>

To be able to use one function, we will need to increase the number of  
simple types to include all the power of 2 vectors up to the maximum  
length that we support, i.e., we will need to add v2i8, v4i8, and  
v2i16 to ValueTypes.h.   The issue is in getTypeAction for the  
extended types.  For integer types, there is no ambiguity between  
promoting vs expanding.  If the integer is not a power of 2, we  
promote it to a power of 2.  Otherwise, we split it in half.  Without  
adding those simple types, we will have an ambiguity for vectors  
because we would have an extended vector types with a power of 2  
length that we want to widen (e.g., v4i8 wants to be widen to v16i8 on  
X86) versus those we would want to split.

> how about driving everything from the type action?  I think you always
> know the new type to widen to, using this algorithm:
>
> ...
> if (type action is widen) {
>  assert(number of elements > 1);
>  do {
>    increase number of elements to next power of 2
>  } while (type action is widen);
>  return vector type with new number of elements
> }
> ...
>
> Thus if v2i32 and v4i32 are marked as needing widening, but v8i32 is  
> not
> marked as needing widening, then getTypeToTransform would return  
> v8i32 for
> both v2i32 and v4i32.
>
> Ciao,
>
> Duncan.
>
> PS: This is the same logic that is used for integers.


Once we have added those vector types to MVT, the logic can be the  
same as what is done for integers.  For an incoming type,  
getTypeToTransform would know if we want to widen or to split.  For  
any simple type, we know if there is a wider type or not.  Any  
extended type that is a power of 2 would not be widened because it  
would be impossible to have a wider legal type so it must be split.   
Any non power of 2 extended type would be widen to a power of 2 and  
checked if there is a widen type for it or not.

I think this is a clean way to go so unless there is some hidden cost  
that I'm not aware of.

   -- Mon Ping

BTW, the algorithm will not be optimal if a machine supports a vectors  
of odd lengths (e.g., 3) but targets who want to support that could  
try to override default getTypeAction and getTypeToTransform by making  
them virtual and defining their own methods for this.