[llvm-dev] Complex proposal v2

David Greene via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 3 07:43:21 PDT 2019


Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes:

>> -----Original Message-----
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David Greene
>> via llvm-dev
>> Sent: Thursday, August 29, 2019 10:05 AM
>> To: llvm-dev <llvm-dev at lists.llvm.org>
>> Subject: [EXT] [llvm-dev] Complex proposal v2
>>
>> [...]
>>
>> llvm.extractreal.* - Overloaded intrinsic to create a vector of
>>                      floating-point type from the real portions of a
>>                      vector of complex (not all variants shown)
>>
>> declare v4f32 @llvm.extractreal.v4c32(v4c32 %val) declare v4f64
>> @llvm.extractreal.v4c64(v4c64 %val)
>>
>> llvm.extractimag.* - Overloaded intrinsic to create a vector of
>>                      floating-point type from the imaginary portions
>>                      of a vector of complex (not all variants shown)
>>
>> declare v4f32 @llvm.extractimag.v4c32(v4c32 %val) declare v4f64
>> @llvm.extractimag.v4c64(v4c64 %val)
>
> I think that "cunzip" returning a pair of vectors would be better.  If
> both results are needed, they could usually be generated by a single
> instruction corresponding to some kind of a shuffle, but in order to
> generate that instruction, the backend would have to see both of the
> "extract*" intrinsics.  With cunzip, if one only wants a single part,
> they can ignore the other element of the pair.

Do you mean return a struct containing two vectors or something else?
If a struct, we'd have to define a new built-in struct type then, right?
Are there other examples of intrinsics (or instructions) that return
pairs?

I agree that a single intrinsic would be better.  I couldn't think of a
good way to do it though.

                         -David


More information about the llvm-dev mailing list