Re: non trivial constant folding

anton@mips.complang.tuwien.ac.at (Anton Ertl)
9 Jan 2001 23:10:11 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: non trivial constant folding mihai@cs.wisc.edu (Mihai Christodorescu) (2001-01-06)
Re: non trivial constant folding pat@jantar.org (Patryk Zadarnowski) (2001-01-06)
Re: non trivial constant folding bonzini@gnu.org (2001-01-06)
Re: non trivial constant folding idbaxter@semdesigns.com (Ira D. Baxter) (2001-01-06)
Re: non trivial constant folding cfc@world.std.com (Chris F Clark) (2001-01-06)
Re: non trivial constant folding anton@mips.complang.tuwien.ac.at (2001-01-09)
Re: non trivial constant folding anton@mips.complang.tuwien.ac.at (2001-01-09)
Re: non trivial constant folding metzger@rsn.hp.com (Robert Metzger) (2001-01-09)
Re: non trivial constant folding sjmeyer@www.tdl.com (2001-01-09)
Re: non trivial constant folding henry@spsystems.net (2001-01-09)
Re: non trivial constant folding dew@cray.com (2001-01-09)
Re: non trivial constant folding mpointie@eden-studios.fr (Mickaƫl Pointier) (2001-01-09)
Re: non trivial constant folding morrell@morrell.cup.hp.com (Michael Morrell) (2001-01-09)
[8 later articles]
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: 9 Jan 2001 23:10:11 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 01-01-015 01-01-022
Keywords: optimize
Posted-Date: 09 Jan 2001 23:10:11 EST

  "Mihai Christodorescu" <mihai@cs.wisc.edu> writes:
> There is also another problem: the optimized expression can behave
>differently than the original expression, due to operations being executed
>in different order/with different operands.


If the original program was code with defined behaviour, differences
in observable behaviour are not optimization, they are an indication
of a broken compiler.


And even if the original code had undefined behaviour, a particular
compiler should implement a consistent behaviour for that, if possible
(for practical reasons, like finding the bug).


> Consider:
> "MAXINT + x - 1"
>If x is 1, then evaluating MAXINT + x will overflow.
>
>If you optimize the expression to be:
> "the_value_of_MAXINT_minus_1 + x"
>(i.e. you evaluate MAXINT - 1 at compile time), then if x is 1, the
>expression will not overflow.


Well, if your + does exception-on-overflow, or saturating arithmetic,
then it is not associative, and you cannot apply this transformation.


OTOH, if your + does modulo arithmetic (aka wrap-around), then it is
associative, and both expressions will give the same result.


So it comes down to: does the operation satisfy the algebraic laws
required by the transformation? If not, you cannot apply the
transformation in an optimizer.


- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.