9 Jan 2001 23:10:11 -0500

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

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.