5 Jan 2001 14:45:28 -0500

Related articles |
---|

non trivial constant folding mpointie@eden-studios.fr (MickaÃ«l Pointier) (2001-01-05) |

Re: non trivial constant folding broeker@physik.rwth-aachen.de (Hans-Bernhard Broeker) (2001-01-05) |

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

[15 later articles] |

From: | Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> |

Newsgroups: | comp.compilers |

Date: | 5 Jan 2001 14:45:28 -0500 |

Organization: | Aachen University of Technology (RWTH) |

References: | 01-01-015 |

Keywords: | arithmetic, optimize, comment |

Posted-Date: | 05 Jan 2001 14:45:28 EST |

Originator: | broeker@ |

"Mickaël Pointier" <mpointie@eden-studios.fr> wrote:

[...]

*> My problem is that I do not manage to find a clean solution*

*> to optimise this:*

*> eval(1+var+1)*

Just a warning, even though there's not much compiler theory behind

it: you're operating in floating point numbers, where neither additive

nor multiplicative operations are truly associative. In that

environment, optimizing this into '2+var' would introduce subtle or

even catastrophic changes in results.

Example, assuming 3 decimal digits of accuracy for illustrative

purpose:

5 + var + (-10), with var happening to be 5.01:

+(+(5, 5.01), -10)

= +(10.0, -10)

= 0

+(5, +(5.01, -10))

= +(5, -4.99)

= 0.01

100% error, just by changing associativity of the opeators. Your

proposed change would have the same kind of effect. It's up to you to

decide whether optimization gains warrant such a potentially

devastating change of result.

--

Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)

[It depends on the definition of the language. Fortran explicitly

says that any optimzation that's mathematically equivalent is fair

game, so if you want to force an order of computation, you have to use

parentheses. But anyway, in practice I've found that this is much

more common with integers, particularly in subscript calculations

where one of the constants is the lower bound of the array. -John]

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.