Hi,
I agree that the more general shufflevector is more useful. I
narrowed the original proposal a little bit because of the concern for
the implementation cost. However, the slightly narrowed definition
will probably require falling backing to generate insert and extracts
for complex masks so it is possible that there will be no extra cost
in supporting the more general definition. If that is the case, it
will make sense to support the more general shuffle vector definition.
-- Mon Ping
On Sep 30, 2008, at 10:36 AM, Evan Cheng wrote:
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev