[LLVMdev] proposal to add MVT::vAny type

[Chris Lattner]

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

>
> On Aug 9, 2009, at 6:29 AM, Dan Gohman wrote:
>
>> Hi Bob,
>>
>> An alternative would be to model the operations as regular shuffle,
>> load, and store operators, combined to describe the actual
>> instructions.  This would make them easier for target-independent  
>> code
>> to understand.
>
> Yes, I have tried to do that as much as possible.  There are still a
> number of operations where we've ended up using intrinsics, for
> varying reasons.
>
> For example, I had been planning to have the front-end translate the
> VTRN, VZIP, and VUZP builtins to vector shuffles, since that is
> exactly what they are.  But, after discussing it with Evan, I changed
> these to intrinsics because we couldn't figure out a good way to
> handle them as shuffles.  They take two vector operands and shuffle
> them in place, producing two vector results.  I had been translating
> these to shuffles that produced double-wide vectors, e.g., shuffle two
> <8 x i8> vectors producing one <16 x i8> vector.  That made it hard
> for the optimizer to deal with the results, since they are really two
> separate vectors, and some simple experiments made me think we won't
> get very good code from that approach.
>
> The load/store multiple with element (de)interleaving operations also
> worked out best as intrinsics.

Yes, these sound very reasonable to keep as intrinsics.  We'd just  
want one intrinsic for each semantic operation, not one for each  
type.  Using bitcasts to canonicalize to one (non-type-parametric)  
intrinsic seems like the right approach.

-Chris