[llvm-commits] Patch: Widening in LegalizeType

Duncan Sands baldrick at free.fr
Fri Nov 21 19:03:47 PST 2008


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.

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.



More information about the llvm-commits mailing list