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]

Re: Reassociation




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


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