From: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Richard Biener <richard.guenther@gmail.com>
Cc: nd <nd@arm.com>, Joseph Myers <joseph@codesourcery.com>
Subject: Re: [PATCH][tree-complex.c] PR tree-optimization/70291: Inline floating-point complex multiplication more aggressively
Date: Thu, 03 May 2018 08:39:00 -0000 [thread overview]
Message-ID: <5AEACABE.6010800@foss.arm.com> (raw)
In-Reply-To: <DB5PR08MB1030DE0893C1AEE0AE29927783800@DB5PR08MB1030.eurprd08.prod.outlook.com>
On 02/05/18 17:45, Wilco Dijkstra wrote:
> Richard Biener wrote:
>
>> why use BUILT_IN_ISUNORDERED but not a GIMPLE_COND with
>> UNORDERED_EXPR? Note again that might trap/throw with -fsignalling-nans
>> so better avoid this transform for flag_signalling_nans as well...
> Both currently trap on signalling NaNs due to the implementation of the C99
> builtins being buggy (PR66462).
>
> However since the inputs are results of FP operations, they are guaranteed
> to be quiet NaNs in this case, so no extra test for signalling NaNs is required.
I'm happy to remove the check on flag_signaling_nans from the patch.
Kyrill
>> Which also means that we can dispatch to this simple variant not only for
>> flag_complex_method != 2 but for !HONOR_NANS && !HONOR_INFINITIES?
>> Maybe that should be done as followup.
> With -ffinite-math-only the isunordered will be optimized anyway. So it's just
> to avoid generating unnecessary dead code.
>
> Wilco
next prev parent reply other threads:[~2018-05-03 8:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-02 16:45 Wilco Dijkstra
2018-05-03 8:39 ` Kyrill Tkachov [this message]
2018-05-03 9:21 ` Richard Biener
2018-05-03 13:00 ` Kyrill Tkachov
-- strict thread matches above, loose matches on Subject: below --
2018-04-30 17:50 Kyrill Tkachov
2018-05-02 10:15 ` Richard Biener
2018-05-02 15:56 ` Kyrill Tkachov
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=5AEACABE.6010800@foss.arm.com \
--to=kyrylo.tkachov@foss.arm.com \
--cc=Wilco.Dijkstra@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=nd@arm.com \
--cc=richard.guenther@gmail.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).