From mboxrd@z Thu Jan  1 00:00:00 1970
From: tprince@cat.e-mail.com
To: bosch@gnat.com, burley@gnu.org, egcs@cygnus.com, hjstein@bfr.co.il, jbuck@Synopsys.COM, law@cygnus.com, moshier@mediaone.net
Subject: RE: REASSOCIATION
Date: Thu, 17 Dec 1998 14:26:00 -0000
Message-id: <4.19981217.17.26.32.859862@cat.e-mail.com>
X-SW-Source: 1998-12/msg00663.html

>>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