Re: Complex numbers support: discussions summary

[Paul Iannetta <piannetta@kalrayinc.com>]

On Tue, Sep 26, 2023 at 09:30:21AM +0200, Richard Biener via Gcc wrote:
> On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > 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).
> 
> Thanks for the detailed presentation at the Cauldron.
> 
> My personal summary is that I'm less convinced delaying lowering is
> the way to go.

This is not only delayed lowering, if the SPN are there, there is no
lowering at all.

> I do think that if targets implement complex optabs we should use them but
> eventually re-discovering complex operations from lowered form is going to be
> more useful.

I would not be opposed to rediscovering complex operations but I think
that even though, rediscovering a + b, a - b is easy, a * b would
still be doable, but even a / b will be hard.  Even though, I doubt
will see a hardware complex division but who knows.  However, once
lowered, re-associating a * b * c and more complex expressions is going
to be hard.

> That's because as you said, use of _Complex is limited and people
> inventing their own representation.

Yes, this would be a step back at first, but, proper support for
_Complex would probably be an incentive for library writers to take
them into account.

> SLP vectorization can discover some ops
> already with the limiting factor being that we don't specifically search for
> only complex operations (plus we expose the result as vector operations,
> requiring target support for the vector ops rather than [SD]Cmode operations).

Our only concern with SLP is that it only works within loops.  If we
want to re-discover complex numbers we could either add a
dedicated pass before the SLP vectorizer or rely on match.pd?

> 
> There's the gimple-isel.cc or the widen-mul pass that perform
> instruction selection
> which could be enhanced to discover scalar [SD]Cmode operations.

We'll have another look there.

Thanks,
Paul
> 
> Richard.
> 
> > Sylvain
> >
> >
> >
> >
> >
> 
> 
> 
>