This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reassociation
- To: bosch at gnat dot com, burley at gnu dot org, egcs at cygnus dot com, hjstein at bfr dot co dot il, jbuck at Synopsys dot COM, law at cygnus dot com, moshier at mediaone dot net
- Subject: Re: Reassociation
- From: tprince at cat dot e-mail dot com
- Date: Wed, 16 Dec 1998 22:37:12 EST
Fortunately, we're not facing the dilemma of needing something
for g77 which is not wanted otherwise. What Jeff has proposed
is in accordance with the excerpts from C9X which I quoted
earlier, as well as being in accordance with Fortran. I doubt that
the C9X people really intended to help out egcs/g77, but they
may have done so in this case.
I suppose the next comment we'll see is "they're trying to make C
look more like Fortran." But, I think there is a sufficient body of
experts who have taken a satisfactory position on what the
proper level of reassociation should be for normal optimization.
gcc and g77 could become examples of this, and provide an
alternative to "all-or-nothing" compilers which try to give a choice
of going too far or not far enough, with a poorly documented
group of options unlike those used for benchmarks needed to
approximate correct behavior. No matter if another flag or two
come into egcs, as long as we don't need to use them to get
reasonable behavior.
>>>
Date: Wed, 16 Dec 1998 12:37:01 -0500 (EST)
From: Craig Burley <>
>There has been general agreement that gcc is not supposed to
make
>optimizations that could change the value of an expression.
>Associative law optimizations of floating-point expressions
certainly
>can change the value and they should continue to be
disallowed. Users
>should not have to fear that gcc is going to take arbitrary
liberties
>and rewrite their programs for them without very explicit
permission.
Even if this was true -- and IMO it isn't -- it doesn't apply to well-
designed numerical-processing languages like Fortran, in which
it
is quite clear that A*B*C*D can be evaluated as (D*A)*(C*B), for
example.
Therefore, we should make the *back end* work properly in a
language-
independent sense. If people want the gcc to produce slower
code
than g77, that's okay -- they can have gcc explicitly group the
operations for consumption by the back end, something Fortran
doesn't
generally need to do.
tq vm, (burley)
Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org
To: INTERNET - IBMMAIL
N3356140 - IBMMAIL