public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/107013] New: Add fmin/fmax to RTL codes
@ 2022-09-23 2:15 guihaoc at gcc dot gnu.org
2023-07-11 1:48 ` [Bug rtl-optimization/107013] " guihaoc at gcc dot gnu.org
2023-07-11 11:58 ` xry111 at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: guihaoc at gcc dot gnu.org @ 2022-09-23 2:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107013
Bug ID: 107013
Summary: Add fmin/fmax to RTL codes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
Could we add fmin/fmax to RTL codes so that the C standard fmin/fmax can be
represented in RTL without UNSPECs? Currently we only have smin/smax that are
not valid for NaNs, or when the sign of zeros is relevant.
C standard for fmax
F.10.9.2 The fmax functions
1 If just one argument is a NaN, the fmax functions return the other argument
(if both arguments are NaNs, the functions return a NaN).
2 The returned value is exact and is independent of the current rounding
direction mode.
3 The body of the fmax function might be374)
{ return (isgreaterequal(x, y) ||
isnan(y)) ? x : y; }
Footnotes
374) Ideally, fmax would be sensitive to the sign of zero, for example
fmax(-0.0, +0.0) would return +0; however, implementation in software might be
impractical.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/107013] Add fmin/fmax to RTL codes
2022-09-23 2:15 [Bug rtl-optimization/107013] New: Add fmin/fmax to RTL codes guihaoc at gcc dot gnu.org
@ 2023-07-11 1:48 ` guihaoc at gcc dot gnu.org
2023-07-11 11:58 ` xry111 at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: guihaoc at gcc dot gnu.org @ 2023-07-11 1:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107013
HaoChen Gui <guihaoc at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joseph at codesourcery dot com
--- Comment #1 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
If fmin/max are added as new RTL codes, the fmin/max unspec in some targets can
be replaced with RTL codes. Do you think it is necessary? If so, I can draft
one. Looking forward to your advice. Thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/107013] Add fmin/fmax to RTL codes
2022-09-23 2:15 [Bug rtl-optimization/107013] New: Add fmin/fmax to RTL codes guihaoc at gcc dot gnu.org
2023-07-11 1:48 ` [Bug rtl-optimization/107013] " guihaoc at gcc dot gnu.org
@ 2023-07-11 11:58 ` xry111 at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-07-11 11:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107013
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xry111 at gcc dot gnu.org
--- Comment #2 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to HaoChen Gui from comment #1)
> If fmin/max are added as new RTL codes, the fmin/max unspec in some targets
> can be replaced with RTL codes. Do you think it is necessary? If so, I can
> draft one. Looking forward to your advice. Thanks.
I've mentioned this in r13-2914, but I'm not sure if a new RTL code is
necessary. And do we need new RTL codes for IEEE-754-2019 style
fminimum/fmaximum too?
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-07-11 11:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-23 2:15 [Bug rtl-optimization/107013] New: Add fmin/fmax to RTL codes guihaoc at gcc dot gnu.org
2023-07-11 1:48 ` [Bug rtl-optimization/107013] " guihaoc at gcc dot gnu.org
2023-07-11 11:58 ` xry111 at gcc dot gnu.org
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).