This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Fix PR28684
On Nov 14, 2006, at 13:02, Richard Guenther wrote:
Well, sure. Following this reasoning having -fiec60559-math (or
whatever
written piece of paper we want to follow exactly) and -ffast-math
(or how we want to call it - "precise" or "exact" are not what I would
name it in the context of the above example).
The problem is distinguishing between the cases where we want
or need to be precise and those where we don't care. Even though
users often write careless code, where replacing a division
by a multiplication of the reciprocal is the least to worry
about, they may be using other code that critically relies
on precise semantics. Your lround code would be an example.
As we're inlining more and more, global options are becoming far
too course.
Of course I like the way Fortran specifies that unless bracketed
in the source, operands can be reordered by the compiler.
This is an entirely reasonable approach, as it gives the possibility
of preventing reassociation in places where we care. For C99, there
is the #pragma STDC CONTRACT OFF. Unfortunately, there is no
infrastructure yet. We could either introduce flags per operation
that indicate wether the operation may be contracted, or have a
separate tree code that would indicate rounding to machine precision.
(This would essentially be the Ada 'Machine attribute.)
Aside from what we present to the user, folding and optimization
passes also need to adhere to some rules - sticking everything under
a flag_unsafe_math_optimizations is easy, getting the various
HONOR_* macros right is not.
It's very easy to go just a bit too far in such flags and make them
unusable.
If the user can identify a class of transformations that hurt them
(like CSEing of reciprocals I ran into multiple times), being able
to just disable that kind of transformations can help them rescue
some of the performance advantage of -ffast-math.
The most worrisome kind is where you don't know you're hurt until
it's too late. As GCC is getting better at optimizing, and optimizations
are getting more global, people are getting bitten more often by
"optimizations" such as reassociation that make it impossible to
do any meaningful numerical analysis.
[I have seen cleverly placed "volatile" temporaries for
intermediate results
too often...]
This is the only way to guard against overly aggressive optimizations
right
now, although it's really horrible. A tree code as described above that
would preserve exact rounding would be far preferable to the use of
volatile variables. It would still be possible to do many optimizations
such as constant propagation and CSE. This new code would also be great
for implementing the Fortran parens rule, Ada 'Machine attribute and
C99's
pragma STDC CONTRACT (ON|OFF).
-Geert