[llvm-dev] RFC: Complex in LLVM

[Krzysztof Parzyszek via llvm-dev]

-----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.).

Granted, if Hexagon is the only one, this case may not be strong enough to convince everybody, but fixed-point complex arithmetic may actually be useful in practice, especially given the recent addition of fixed-point functionality to clang/llvm.  As per your RFC, the issue is with keeping the "intent" clear, which may be lost once complex operations are expanded into the underlying arithmetic (especially if parts of it are simplified).  The way I look at it is that if we want to preserve that arithmetic in a single unit, then we should start with that, and leave the input types for later.  To be even more explicit, I'd suggest that we should instead have intrinsics for complex operations (and have clang generate them automatically for the standard C complex types), and not bother with defining a complex type in the LLVM IR at all.

-Krzysztof