[llvm-dev] Complex proposal v3 + roundtable agenda

[Krzysztof Parzyszek via llvm-dev]

I missed the proposal for a first-class complex type, so I was thinking about working directly on pairs of numbers.

I still think that intrinsics are better than a complex type.  Intrinsics can be type-agnostic (i.e. overloaded), which would allow them to operate on complex number with any underlying type.  Most applications want floating-point values, but on Hexagon we may want to use int16.

Complex type would pose another issue for vectorization: in general it's better to have a vector of the real parts and a vector of the imaginary parts for the purpose of arithmetic, than having vectors of complex elements (i.e. real and imaginary parts interleaved).

--
Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development

-----Original Message-----
From: David Greene <greened at obbligato.org>
Sent: Wednesday, November 18, 2020 3:13 PM
To: Krzysztof Parzyszek <kparzysz at quicinc.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] Complex proposal v3 + roundtable agenda

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

> Examples of complex instructions?

Sorry, I was referring specifically to this statement:

>> Without intrinsics it may be hard to use such instructions especially
>> because of the arithmetic simplifications.

I was asking the question in the context of intrinsics vs. a first-class complex type.  Matching things like hardware support for complex multiply is doable with either mechanism.  Your statement made it sound like intrinsics were needed to *avoid* simplifcations in order to match them to hardware instructions and that a first-class complex type (using "normal" LLVM arithmetic instructions) would not be matchable to some hardware instructions.  I was curious about what those cases would be.

                -David