Re: inlining + optimization = nuisance bugs

Chris F Clark <cfc@world.std.com>
10 Aug 1998 23:31:30 -0400

          From comp.compilers

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]
| List of all articles for this month |

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.