From: Joseph Myers <joseph@codesourcery.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Roger Sayle <roger@nextmovesoftware.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [RFC] Experimental __attribute__((saturating)) on integer types.
Date: Mon, 27 Sep 2021 20:33:59 +0000 [thread overview]
Message-ID: <alpine.DEB.2.22.394.2109272015480.3687803@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CAFiYyc0TVqe4e01vi32K54j-PUKSaR2PQeqEDR_Hy22B_gp9BA@mail.gmail.com>
On Mon, 27 Sep 2021, Richard Biener via Gcc-patches wrote:
> Now - ISTR that elsewhere Joseph suggested that taking on
> saturating operations by type was eventually misguided and we should
> have instead added saturating arithmetic tree codes that we could
> expose via some builtin functions like the overflow ones.
There are several issues there:
* saturating (and other fixed-point) types at the C API level;
* saturating (and other fixed-point) types in GIMPLE;
* saturating (and other fixed-point) modes in RTL.
As I said in
<https://gcc.gnu.org/legacy-ml/gcc-patches/2011-05/msg00846.html>, I think
having special modes for these kinds of types is a bad idea, because
operations should be lowered to ordinary integer arithmetic at some point
in GIMPLE, or at the latest in expand. (Maybe a few cases would sensibly
use libgcc functions rather than inline arithmetic, but those would be the
exception. We handle inline expansion of the overflow-checking built-in
functions in general, much of that code could be shared to expand
saturating arithmetic in general on hardware lacking the operations.) At
present, there are loads of fixed-point machine modes, and very many
libgcc functions on the targets supporting fixed-point, and very little
optimization done on these operations, when if the operations were lowered
to normal arithmetic earlier, generic code in the compiler could optimize
them. (Back ends would still need to know enough about the types in
question to be able to implement any desired ABI differences from the
underlying ordinary integer types.)
My inclination is that GIMPLE should also use saturating operations rather
than saturating types.
At the C API level it's less clear. When you have saturating types in the
front end - as in those we currently have implemented, from the Embedded C
TR, for example - at some point they need lowering to saturating
operations on normal types, if you follow my suggested model above. That
could be at gimplification, or you could allow saturating types in GIMPLE
but then have some early pass that replaces them by normal types using
saturating operations.
For some kinds of algorithm, saturating types may well be a convenient
abstraction for the user. For others, saturating operations on normal
types may make more sense (e.g. using saturating arithmetic on size_t to
compute an allocation size, knowing that SIZE_MAX will result in
allocation failure if passed to an allocation function).
As for the specific patch: it looks like you create a new type every time
the user uses the attribute. If you allow users to create such saturating
types (distinct from the fixed-point ones) at all, I think that every time
someone requests int __attribute__ ((saturating)) it should produce the
same type (and likewise for each other underlying non-saturating integer
type, and watch out for any interactions with types created for
bit-fields). Then there would be API design questions to address such as
the results of converting out-of-range integer or floating-point values -
or, for that matter, wider pointers - to a saturating type.
--
Joseph S. Myers
joseph@codesourcery.com
prev parent reply other threads:[~2021-09-27 20:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-26 20:37 Roger Sayle
2021-09-27 13:45 ` Richard Biener
2021-09-27 20:33 ` Joseph Myers [this message]
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=alpine.DEB.2.22.394.2109272015480.3687803@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
--cc=roger@nextmovesoftware.com \
/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).