This is the mail archive of the 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]

Re: Draft "Unsafe fp optimizations" project description.

----- Original Message -----
From: <>
To: <>; <>;
Cc: <>; <>
Sent: Sunday, August 05, 2001 4:40 AM
Subject: Re: Draft "Unsafe fp optimizations" project

> <<One of my original reasons for provoking this discussion
was my hope of
> dealing with the need to conform with C and Fortran
standards, which
> require re-association to be preventable by parentheses,
even though
> optimizations such as -ffast-math are in effect.  According
to my
> >>
> No, that's wrong, there is nothing to prevent -ffast-math
from ignoring
> parentheses in Fortran. The Fortran standard has nothing to
say about
> compiler switches that deliberately provide other than
standard semantics,
> and such switches are perfectly reasonable.
> Remember that in Fortran, one might use parens to override
> or simply for documentation purposes. The fact that these
intefere with
> desired optimizations might be annoying in some
circumstances, and if
> you take the "anything goes, speed all important" viewpoint
> -ffast-math, then it would be entirely reasonable to have
this switch
> override the effect of parens.
> Indeed that's what makes sense to me in Fortran. After all
it is allowable
> by default in the absence of parens to do some of the
> we have been discussing here, so I would think
that -ffast-math in
> Fortran would be about forcing additional freedom beyond
that provided
> by the standard.
> A Fortran expert writes parens where needed, and is not
allowed to be
> surprised by transformations in the absence of parens (of
course there's
> still discussion there, but the use of parens is in any case
good style
> to ensure canonical evaluation semantics).

At present, -ffast-math has to be invoked in order to get many
of the optimizations expected in Fortran.  It should be
possible to select between the optimizations which are
somewhat risky and not permitted by IEEE, but expected
according to Fortran, and those which may exceed the bounds
set by Fortran.  As Toon mentioned, placing too many
additional transformations under -ffast-math without options
to shut them off may prevent the use of -ffast-math in
situations where it is useful now.  I face this problem daily
with commercial compilers, more so with C++, where the choices
are between very little optimization with insufficient
performance, and a broken application.

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