[LLVMdev] type legalizer promoting BUILD_VECTORs

[Bob Wilson]

On Feb 2, 2009, at 1:51 PM, Eli Friedman wrote:

> On Mon, Feb 2, 2009 at 11:31 AM, Bob Wilson <bob.wilson at apple.com>  
> wrote:
>> LLVM's type legalizer is changing the types of BUILD_VECTORs in a way
>> that seems wrong to me, but I'm not sure if this is a bug or if some
>> targets may be relying on it.
>>
>> On a 32-bit target, the default action for legalizing i8 and i16  
>> types
>> is to promote them.
>
> This isn't true on x86.

No, it's not, but it is that way on PowerPC.

>
>> If you then have a BUILD_VECTOR to construct a
>> legal vector type composed of i8 or i16 values, the type legalizer
>> will look at the BUILD_VECTOR operands and decide that it needs to
>> promote them to i32 types.  You end up with a BUILD_VECTOR that
>> constructs a vector of i32 values that are then bitcast to the
>> original vector type.
>
> I'm pretty sure the target-independent legalizer does no such thing.
> Can you point to the code you're talking about?

In DAGTypeLegalizer::run(), the loop after the "ScanOperands" label  
looks at the operands of the BUILD_VECTOR and the getTypeAction method  
returns PromoteInteger (because i8 and i16 are promoted to fit in 32- 
bit registers on PPC).

>
>
> That said, I do recall the x86 backend does a similar
> platform-specific transformation with constants... do you care about
> x86 in particular?
>
>> This works fine for SSE, where it appears that BUILD_VECTORs are
>> intentionally canonicalized to use i32 elements for the benefit of
>> CSE.  I'm looking at implementing something where I think I'd like to
>> keep the original vector types.  Is this behavior in the type
>> legalizer something that should be changed?
>
> I'm not sure what behavior you're talking about...


If I have a BUILD_VECTOR that creates a v16i8 type, and v16i8 is a  
legal type for the target that does not require any promotion or  
expansion, I would not expect the type legalizer to change it.  But,  
it does.  It looks at the i8 elements and decides that they need to be  
promoted to i32, so it changes the BUILD_VECTOR to create a v4i32  
vector, which is then bitcast back to v16i8.

I'm not specifically working on SSE right now, I was just explaining  
why this issue doesn't arise for that target.