10 Aug 1998 23:31:30 -0400

Related articles |
---|

inlining + optimization = nuisance bugs qjackson@wave.home.com (Quinn Tyler Jackson) (1998-06-18) |

Re: inlining + optimization = nuisance bugs bill@amber.ssd.csd.harris.com (1998-06-19) |

Re: inlining + optimization = nuisance bugs acoetmeur@icdc.caissedesdepots.fr (Alain Coetmeur) (1998-06-24) |

Re: inlining + optimization = nuisance bugs qjackson@wave.home.com (Quinn Tyler Jackson) (1998-08-10) |

Re: inlining + optimization = nuisance bugs cfc@world.std.com (Chris F Clark) (1998-08-10) |

Re: inlining + optimization = nuisance bugs darcy@usul.CS.Berkeley.EDU (1998-08-13) |

Re: inlining + optimization = nuisance bugs darcy@usul.CS.Berkeley.EDU (1998-08-13) |

Re: inlining + optimization = nuisance bugs joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-08-17) |

Re: inlining + optimization = nuisance bugs lindahl@cs.virginia.edu (1998-08-19) |

Re: inlining + optimization = nuisance bugs jfc@mit.edu (1998-08-19) |

Re: inlining + optimization = nuisance bugs joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-08-19) |

[23 later articles] |

From: | Chris F Clark <cfc@world.std.com> |

Newsgroups: | comp.compilers |

Date: | 10 Aug 1998 23:31:30 -0400 |

Organization: | The World Public Access UNIX, Brookline, MA |

References: | 98-08-056 |

Keywords: | optimize, arithmetic |

Quinn Tyler Jackson (qjackson@wave.home.com)

found a common bug in a compiler's optimization of floating point, and asked:

*> To trust or not to trust?*

The sad answer in general is not to trust (at least with floating

point). When I worked at Prime computer we wrote a new optimizer for

our compilers (see the other thread on multiple languages v. one

backend), and some of the optimizations involved avoiding loads and

stores of floating point results. Thankfully there was a beta test

and we discovered that we broke someones quadratic equation solver

(i.e. the discriminant came out positive because the extra bits in the

register versus the memory worked out that way). Of course, there

were also some samples where the extra bits simply improved accuracy

as they should have and helped some sequences converge faster. The

end result, we added an "unsafe optimization flag" which turned those

particular optimizations on/off. As you can see the Microsoft people

did the same thing, they just left the default at unsafe.

I, myself, have avoided floating point as much as possible since. I

trust it to give me the right result when I divide two integers and

want a percentage to print and for little more than that. (By the

way, I also listen to the other rule of thumb, which is to never

compare two floating point numbers for equality, only for being "close

enough".) If something really requires floating point calculations,

I'd rather pay a numerical analyst to do the necessary thinking about

whether the algorithm is well-behaved and what its error tolerance

is. Real numeric computation is at least as hard as writing compilers.

-Chris

*****************************************************************************

Chris Clark Internet : cfc@world.std.com

Compiler Resources, Inc. CompuServe : 74252,1375

3 Proctor Street voice : (508) 435-5016

Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)

------------------------------------------------------------------------------

Web Site in Progress: Web Site : http://world.std.com/~compres

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.