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: Thu, 17 Dec 1998 17:26:32 EST
>>While I agree that the front end needs a way to tell the
backend
about what it can and can't optimize, I'm not sure parens in the
tree are the best way to do this. (I've not been able to think this
completely through, and so it may be bunk, but I wanted to say
something
before I forgot.)<<
Not that I care about implementation details, but it probably
doesn't need a new mechanism. The same code generation
should come about whether it's written
(a*b)*c)*d
or (too clumsily for normal source code, but the way it was done
in K&R C)
temp= a * b
temp *= c
temp * d
with the reassociation being permitted only when neither
parentheses nor assignments intervene.
>> Do we need separate flags
for each kind of side effect (care-about-overflow,
dont-care-about-underflow)?<<
Not AFAIK for C or Fortran based languages. What we're talking
about is the ability to let the programmer choose between
specifying the order of evaluation, without the translator caring
why, or letting the translator exploit the usual associativity rules
to come up with more efficient scheduling.
We're not even giving the translator the option of saying we know
that we're running on a target with extra exponent range, so the
over/under-flow which the programmer must have been
guarding against can't happen here.
Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org
To: INTERNET - IBMMAIL
N7683011 - IBMMAIL