[LLVMdev] Generalizing shuffle vector

[Evan Cheng]

I agree further generalization seems like a very good idea. But I'd  
like to see what Mon Ping proposed implemented first so we have a  
better idea of the implementation cost.

Thanks,

Evan

On Sep 30, 2008, at 6:44 AM, Stefanus Du Toit wrote:

> Hi Mon Ping,
>
> Generalizing shufflevector would be great. I have an additional
> suggestion below.
>
> On 29-Sep-08, at 11:11 PM, Mon Ping Wang wrote:
>> I am proposing to extend the shuffle vector definition to be
>> <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32>
>> <mask> ; yields <m x <ty>>
>>
>> The third argument is the shuffle mask and it is not required to
>> have the same number of elements as the other vector type but the
>> element type is still always 'i32'
>
> I've previously proposed an even further generalization of
> shufflevector to:
>
> <result> = shufflevector <n1 x <ty>> <v1>, <n2 x <ty>> <v2>, <m x i32>
> <mask> ; yields <m x <ty>>
>
> where n1 does not have the be the same as n2. This makes shufflevector
> completely generic, and in fact allows even insertelement and
> extractelement to be represented using it (not that I necessarily
> think they should be, it's just a nice side effect).
>
> If this is feasible, it would be nice to extend it all the way. This
> lets you do things like:
>
> float3 x;
> float4 y;
>
>  // ...
>
> y.xyz = x;
>
> as a single shufflevector, e.g.:
>
>   %y2 = shufflevector <4xf32> %y1, <3xf32> %x, <4, 5, 6, 3>
>
> I assume my proposed generalization can't hurt codegen, since it could
> always be turned into a sequence of insert and extracts which would
> provide the same behaviour as today.
>
> --
> Stefanus Du Toit <stefanus.dutoit at rapidmind.com>
>   RapidMind Inc.
>   phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev