From: Sylvain Noiry <snoiry@kalrayinc.com>
To: gcc@gcc.gnu.org
Cc: sylvain.noiry@hotmail.fr
Subject: Complex numbers support: discussions summary
Date: Mon, 25 Sep 2023 17:15:56 +0200 [thread overview]
Message-ID: <fdad276c-cee8-3538-4239-823c5da81602@kalrayinc.com> (raw)
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
next reply other threads:[~2023-09-25 15:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-25 15:15 Sylvain Noiry [this message]
2023-09-26 7:30 ` Richard Biener
2023-09-26 8:29 ` Tamar Christina
2023-09-26 10:19 ` Paul Iannetta
2023-09-26 8:53 ` Paul Iannetta
2023-09-26 9:28 ` Tamar Christina
2023-09-26 9:40 ` Paul Iannetta
2023-09-26 18:40 ` Toon Moene
2023-10-05 14:45 ` Toon Moene
2023-09-26 15:46 ` Joseph Myers
-- strict thread matches above, loose matches on Subject: below --
2023-10-16 9:14 Sylvain Noiry
2023-10-17 20:37 ` Toon Moene
2023-10-18 7:24 ` Sylvain Noiry
2023-10-09 13:29 Sylvain Noiry
2023-09-25 14:56 Sylvain Noiry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fdad276c-cee8-3538-4239-823c5da81602@kalrayinc.com \
--to=snoiry@kalrayinc.com \
--cc=gcc@gcc.gnu.org \
--cc=sylvain.noiry@hotmail.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).