public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/47990] New: Missed promotion of double precision constants to single precision for -funsafe-math-optimizations
@ 2011-03-04 14:42 rguenth at gcc dot gnu.org
2011-03-04 15:43 ` [Bug middle-end/47990] " joseph at codesourcery dot com
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-03-04 14:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47990
Summary: Missed promotion of double precision constants to
single precision for -funsafe-math-optimizations
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: rguenth@gcc.gnu.org
In 482.sphinx3 we have code like
float foo (float x, float y)
{
return ((int)(x/y + 0.5)) * y;
}
where the addition of 0.5 is performed in double precision. With
-funsafe-math-optimizations we can demote 0.5 to single precision
(its exactly representable) also because the result of the addition
does not take part of further floating point computation but is
immediately converted to int.
The unsafe part of this optimization occurs when x/y is FLT_MAX
and we'd truncate to a 64bit integer type. For 32bit integers
it would probably be safe to do this optimization unconditionally.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/47990] Missed promotion of double precision constants to single precision for -funsafe-math-optimizations
2011-03-04 14:42 [Bug middle-end/47990] New: Missed promotion of double precision constants to single precision for -funsafe-math-optimizations rguenth at gcc dot gnu.org
@ 2011-03-04 15:43 ` joseph at codesourcery dot com
2011-08-01 13:07 ` rguenth at gcc dot gnu.org
2021-12-26 13:00 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: joseph at codesourcery dot com @ 2011-03-04 15:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47990
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-03-04 15:42:39 UTC ---
On Fri, 4 Mar 2011, rguenth at gcc dot gnu.org wrote:
> In 482.sphinx3 we have code like
>
> float foo (float x, float y)
> {
> return ((int)(x/y + 0.5)) * y;
> }
>
> where the addition of 0.5 is performed in double precision. With
> -funsafe-math-optimizations we can demote 0.5 to single precision
> (its exactly representable) also because the result of the addition
> does not take part of further floating point computation but is
> immediately converted to int.
>
> The unsafe part of this optimization occurs when x/y is FLT_MAX
> and we'd truncate to a 64bit integer type. For 32bit integers
> it would probably be safe to do this optimization unconditionally.
No, that's not safe unconditionally; consider x/y == 0x800001p0f, for
example (so adding 0.5f and converting to float results in rounding up to
the next integer in the default round-to-nearest mode, whereas conversion
from floating point to integer in C always rounds towards zero).
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/47990] Missed promotion of double precision constants to single precision for -funsafe-math-optimizations
2011-03-04 14:42 [Bug middle-end/47990] New: Missed promotion of double precision constants to single precision for -funsafe-math-optimizations rguenth at gcc dot gnu.org
2011-03-04 15:43 ` [Bug middle-end/47990] " joseph at codesourcery dot com
@ 2011-08-01 13:07 ` rguenth at gcc dot gnu.org
2021-12-26 13:00 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-08-01 13:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47990
--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-01 13:07:00 UTC ---
The intel compiler does not perform this optimization even at -fast. It does
perform the demotion on
float foo (float x, float y)
{
return (int)((float)(x/y + 0.5)) * y;
}
though, even with default optimization (also with the conversion to
int removed or associated to apply to the first operand of the
multiplication only).
So they leave alone what looks like a usual "rounding" pattern.
My original idea was to fold (int)((double)(x/y) + 0.5) to (int)(x/y + 0.5f),
similar to (float)((double)(x/y) + 0.5) to (x/y + 0.5f) which we already
do (at -O0, in convert_to_real).
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/47990] Missed promotion of double precision constants to single precision for -funsafe-math-optimizations
2011-03-04 14:42 [Bug middle-end/47990] New: Missed promotion of double precision constants to single precision for -funsafe-math-optimizations rguenth at gcc dot gnu.org
2011-03-04 15:43 ` [Bug middle-end/47990] " joseph at codesourcery dot com
2011-08-01 13:07 ` rguenth at gcc dot gnu.org
@ 2021-12-26 13:00 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-26 13:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47990
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-12-26 13:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-04 14:42 [Bug middle-end/47990] New: Missed promotion of double precision constants to single precision for -funsafe-math-optimizations rguenth at gcc dot gnu.org
2011-03-04 15:43 ` [Bug middle-end/47990] " joseph at codesourcery dot com
2011-08-01 13:07 ` rguenth at gcc dot gnu.org
2021-12-26 13:00 ` pinskia 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).