Hi,
We had very interesting discussions during our presentation with Paul on
the
support of complex numbers in gcc at the Cauldron.
Thank you all for your participation !
Here is a small summary from our viewpoint:
- Replace CONCAT with a backend defined internal representation in RTL
--> No particular problems
- Allow backend to write patterns for operation on complex modes
--> No particular problems
- Conditional lowering depending on whether a pattern exists or not
--> Concerns when the vectorization of split complex operations performs
better
than not vectorized unified complex operations
- Centralize complex lowering in cplxlower
--> No particular problems if it doesn't prevent IEEE compliance and
optimizations (like const folding)
- Vectorization of complex operations
--> 2 representations (interleaved and separated real/imag): cannot
impose one
if some machines prefer the other
--> Complex are composite modes, the vectorizer assumes that the inner
mode is
scalar to do some optimizations (which ones ?)
--> Mixed split/unified complex operations cannot be vectorized easely
--> Assuming that the inner representation of complex vectors is let to
target
backends, the vectorizer doesn't know it, which prevent some
optimizations
(which ones ?)
- Explicit vectors of complex
--> Cplxlower cannot lower it, and moving veclower before cplxlower is a
bad
idea as it prevents some optimizations
--> Teaching cplxlower how to deal with vectors of complex seems to be a
reasonable alternative
--> Concerns about ABI or indexing if the internal representation is let
to the
backend and differs from the representation in memory
- Impact of the current SLP pattern matching of complex operations
--> Only with -ffast-math
--> It can match user defined operations (not C99) that can be
simplified with a
complex instruction
--> Dedicated opcode and real vector type choosen VS standard opcode and
complex
mode in our implementation
--> Need to preserve SLP pattern matching as too many applications
redefines
complex and bypass C99 standard.
--> So need to harmonize with our implementation
- Support of the pure imaginary type (_Imaginary)
--> Still not supported by gcc (and llvm), neither in our implementation
--> Issues comes from the fact that an imaginary is not a complex with
real part
set to 0
--> The same issue with complex multiplication by a real (which is split
in the
frontend, and our implementation hasn't changed it yet)
--> Idea: Add an attribute to the Tree complex type which specify pure
real / pure
imaginary / full complex ?
- Fast pattern for IEEE compliant emulated operations
--> Not enough time to discuss about it
Don't hesitate to add something or bring more precision if you want.
As I said at the end of the presentation, we have written a paper which
explains
our implementation in details. You can find it on the wiki page of the
Cauldron
(https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).
Sylvain
