[llvm-dev] RFC: Complex in LLVM

[Bevin Hansson via llvm-dev]

On 2019-07-04 03:06, Chris Lattner via llvm-dev wrote:
>
>> On Jul 3, 2019, at 4:43 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> -----Original Message-----
>> From: David Greene <dag at cray.com>
>> Sent: Wednesday, July 3, 2019 2:44 PM
>> To: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org>
>> Cc: Krzysztof Parzyszek <kparzysz at quicinc.com>
>> Subject: [EXT] Re: [llvm-dev] RFC: Complex in LLVM
>>
>> Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>
>>>> In addition to that, we shouldn't limit complex types to floating
>>>> point only.  What we care about is keeping the "ac-bd" together, not
>>>> what type a,b,c,d are.
>>> Can you give some examples of non-FP types where a higher-level representation would be useful?
>> Hexagon has instructions to do complex multiplication on pairs i16 x i16 (plus variants like accumulate, conjugate, etc.).

Our downstream target would also benefit from this, for both complex 
integer and complex fixed-point operations. Just having an integer 
representation would be fine even for the latter case though, so long as 
it was generic (complex iN, for any N).

> How difficult are these to pattern match on scalar code?

Typically matching patterns like complex multiplication are very 
sensitive to noise introduced by other optimizations. Having the scalar 
patterns change even slightly from what the frontend emits makes 
selecting the operations much harder. They usually involve complex 
diamonds and multi-result patterns that ISelDAG has trouble with even today.

Having an explicit type representation would also make it easier to keep 
the complex values together as one. Clang's struct-pair representation 
today is often broken up by SROA even though it might have been more 
desirable to keep the real and imaginary parts together in the same 
register. That's harder to accomplish when all LLVM knows is that it's a 
struct.

/ Bevin