This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -ffast-math and floating point reordering


On Fri, Mar 26, 2004 at 09:21:26AM -0700, law@redhat.com wrote:
> In message <20040324170719.A12420@synopsys.com>, Joe Buck writes:
>  >If -ffast-math is not specified, we should follow the language standards.
>  >First question: can tree-ssa distinguish, for Fortran, whether parentheses
>  >were present and so whether reordering is allowed?
> No.  The front-ends don't pass enough information around in the tree nodes
> to know when such changes are safe/unsafe.  Even if the information existed
> none of the optimizers would know how to use it (at least initially).

This should be considered a design bug, as it forces GCC to be inferior
to competing Fortran compilers.

One possible representation in GIMPLE would be a flag indicating that a
temporary can be, well, I'll call it "refactored" (feel free to suggest a
better word).  That is, given GIMPLE code like

	t1 = a + b;
	t2 = t1 + c;
	e = t2 + d;

if the original Fortran input was

   	e = a + b + c + d

then t1 and t2 would be tagged as refactorable, while if the original
input were

	d = ((a + b) + c) + d

then t1 and t2 would not be so tagged.  In the first case, we would
probably want to produce

	t1 = a + b;
	t2 = c + d;
	e = t1 + t2;

since the first two additions can now be performed in parallel.  But
this transformation is not legal in the second case.

For temporaries marked as refactorable, optimizers are allowed to replace
use of the temporary by the expression that computes it, and do
transformations on that expression, even if the tranformation doesn't
guarantee that roundoffs and overflows will be the same.  If the temporary
is not marked as refactorable, this is not permitted.

With such a rule, the language-independent middle end can implement
Fortran or C semantics correctly, and it would be possible to relax the
rules in a controlled manner as well:. the user could ask the C front
end to implement the Fortran rules (respect parentheses but otherwise
allow rearrangement), or the K&R rules (all rearrangements that are
correct for real numbers are allowed), but by default the compiler would
follow the standard.






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]