Messages in this thread | | | Date | Sun, 30 Jan 2000 19:58:41 +0100 | From | Jamie Lokier <> | Subject | Re: Preventing gcc from aligning stack??? |
| |
Horst von Brand wrote: > > > Why should gcc spill a double (i.e. 64bit) as extended precision ? > > > So that the behaviour of a program does not depend on whether a register > > is spilled. So that you get consistent results from the same code. > > Floationg point code is by its very nature inexact. To force "exactness" on > it (at the cost of a very sizable performance loss) is not very > realistic.
I didn't say exact, I said consistent. That means the same code should give the same answers. Floating point code _can_ guarantee that.
> > Numerical codes, simple things like minimum finders and iterative > > solvers, depend on such behaviour. > > How? An example, please.
I don't do numerical stuff so really someone else should write this. But since I mentioned it, I'll bring in some examples from the top of my head.
Ex1.
You have a bracketing minimum finder thats used for optimising a non-linear control system. It evaluates the function its minimising in two different places. It's written exactly the same way in both places -- perhaps its in an inline function.
The properties of floating point numbers are being relied on. Such as a > b and c > 0 implies a*c > b*c.
Due to register allocation, you're getting different calculations at the different places. You're comparing them to test for convergence and it isn't working... It would work if both evaluations gave consistent results.
Ex2.
You run a program. You collect results. You add a line to some function. You run the program again and collect results. You run `diff'.
For some reason your results are totally different. They shouldn't be: all results coming from the same source code should be the same. But they're not, due to different register allocation decisions by the compiler.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |