[LLVMdev] proposal to add MVT::vAny type

[Bob Wilson]

On Aug 9, 2009, at 1:41 PM, Bob Wilson wrote:

> On Aug 9, 2009, at 8:37 AM, Chris Lattner wrote:
>>
>> Can you describe a bit more about what fAny would do for you, maybe
>> with an example?  I'm sorry that I don't know much at all about
>> neon...
>
> It doesn't do anything fundamental.  It just seems like a better fit.
> Neon has vectors of both integers and floats.  Currently my choices
> for describing the type constraints for a Neon intrinsic are iAny or
> fAny, but those also allow scalars.  vAny would more accurately
> indicate that only vector types are allowed, and it would also avoid
> the need for bitcasting.
>
> It sounds like it is not a popular idea, so I'll let it rest.

So I tried adding bitcasts today and it turned out to be harder than I  
expected.  The intrinsics are returning first-class aggregates  
containing values with overloaded types.  If I bitcast the source  
operands and use the v*i32 intrinsic instead of a v*f32 intrinsic, the  
type of the result is completely different than the expected aggregate  
type.  I would have to extract the individual elements, bitcast them  
back to floating-point values, and then insert them into a new  
aggregate with a type that matches what the front-end is expecting.   
It is messy.

I talked about this with Chris and he agreed that adding vAny would  
not be so bad.  I discovered this afternoon that there are a number of  
additional intrinsics I can remove with this change (beyond what I was  
originally thinking of).  These are all operations where the behavior  
differs between i32 and f32 element types so bitcasting is not an  
option.  That is good!

Even better, Chris showed me a way to implement VZIP, VUZP, and VTRN  
as shuffles instead of intrinsics....