From: Moritz Klammler <moritz@klammler.eu>
To: gcc-patches@gcc.gnu.org
Cc: Tamar Christina <Tamar.Christina@arm.com>
Subject: Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible
Date: Mon, 12 Sep 2016 17:24:00 -0000 [thread overview]
Message-ID: <87eg4pav9w.fsf@klammler.eu> (raw)
In-Reply-To: Tamar Christina's message of "Mon\, 12 Sep 2016 16\:19\:32 +0000 \(34 minutes\, 33 seconds ago\)"
[-- Attachment #1.1: Type: text/plain, Size: 2858 bytes --]
Tamar Christina <Tamar.Christina@arm.com> writes:
> Hi All,
>
> This patch adds an optimized route to the fpclassify builtin
> for floating point numbers which are similar to IEEE-754 in format.
>
> [...]
I might be the least competent person on this list to review this patch
but nevertheless read it out of interest and stumbled over a comment
that I believe could be improved for clarity.
diff --git a/gcc/real.h b/gcc/real.h
index 59af580e78f2637be84f71b98b45ec6611053222..36ded57cf4db7c30c935bdb24219a167480f39c8 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -161,6 +161,15 @@ struct real_format
bool has_signed_zero;
bool qnan_msb_set;
bool canonical_nan_lsbs_set;
+
+ /* This flag indicates whether the format can be used in the optimized
+ code paths for the __builtin_fpclassify function and friends.
+ The format has to have the same NaN and INF representation as normal
+ IEEE floats (e.g. exp must have all bits set), most significant bit must be
+ sign bit, followed by exp bits of at most 32 bits. Lastly the floating
+ point number must be representable as an integer. The base of the number
+ also must be base 2. */
+ bool is_binary_ieee_compatible;
const char *name;
};
My first issue is that
> The format has to have the same NaN and INF representation as normal
> IEEE floats
is kind of an oxymoron because NaNs and INFs are not "normal" IEEE
floats.
Second,
> the floating point number must be representable as an integer
is also somewhat misleading because it could be interpreted in the
(obviously nonsensical) way that the floating-point *values* have to be
integral. (I think it should be possible to *interpret* not *represent*
them as integers.)
So I would like to suggest the following rewording.
> This flag indicates whether the format is suitable for the optimized
> code paths for the __builtin_fpclassify function and friends. For
> this, the format must be a base 2 representation with the sign bit as
> the most-significant bit followed by (exp <= 32) exponent bits
> followed by the mantissa bits. It must be possible to interpret the
> bits of the floating-point representation as an integer. NaNs and
> INFs must be represented by the same schema used by IEEE 754. (NaNs
> must be represented by an exponent with all bits 1, any mantissa
> except all bits 0 and any sign bit. +INF and -INF must be represented
> by an exponent with all bits 1, a mantissa with all bits 0 and a sign
> bit of 0 and 1 respectively.)
I Hope this is clearer and still matches what the comment was supposed
to say.
--
OpenPGP:
Public Key: http://openpgp.klammler.eu
Fingerprint: 2732 DA32 C8D0 EEEC A081 BE9D CF6C 5166 F393 A9C0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]
next reply other threads:[~2016-09-12 17:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-12 17:24 Moritz Klammler [this message]
2016-09-12 20:08 ` Andrew Pinski
-- strict thread matches above, loose matches on Subject: below --
2016-09-13 12:16 Wilco Dijkstra
2016-09-13 16:10 ` Joseph Myers
2016-09-21 14:51 ` Richard Earnshaw (lists)
2016-09-12 16:21 Tamar Christina
2016-09-12 22:33 ` Joseph Myers
2016-09-13 12:25 ` Tamar Christina
2016-09-12 22:41 ` Joseph Myers
2016-09-13 12:30 ` Tamar Christina
2016-09-13 12:44 ` Joseph Myers
2016-09-15 9:08 ` Tamar Christina
2016-09-15 11:21 ` Wilco Dijkstra
2016-09-15 12:56 ` Joseph Myers
2016-09-15 13:05 ` Joseph Myers
2016-09-12 22:49 ` Joseph Myers
2016-09-13 12:33 ` Tamar Christina
2016-09-13 12:48 ` Joseph Myers
2016-09-13 8:58 ` Jakub Jelinek
2016-09-13 16:16 ` Jeff Law
2016-09-14 8:31 ` Richard Biener
2016-09-15 16:02 ` Jeff Law
2016-09-15 16:28 ` Richard Biener
2016-09-16 19:53 ` Jeff Law
2016-09-20 12:14 ` Tamar Christina
2016-09-20 14:52 ` Jeff Law
2016-09-20 17:52 ` Joseph Myers
2016-09-21 7:13 ` Richard Biener
2016-09-19 22:43 ` Michael Meissner
[not found] ` <41217f33-3861-dbb8-2f11-950ab30a7021@arm.com>
2016-09-20 21:27 ` Michael Meissner
2016-09-21 2:05 ` Joseph Myers
2016-09-21 8:32 ` Richard Biener
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=87eg4pav9w.fsf@klammler.eu \
--to=moritz@klammler.eu \
--cc=Tamar.Christina@arm.com \
--cc=gcc-patches@gcc.gnu.org \
/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).