Should -fcross-jumping be part of -O1?
Robert Dewar
dewar@gnat.com
Thu Dec 4 07:33:00 GMT 2003
> I know. There are many and many. Many users of fpt also can't
> understand why someone would value speed over correctness when
> correctness is the purpose of the computation.
That's going too far. When you get different results in a Fortran
compiler at -O0 and -O2, then there is no absolute judgment that one
semantics is more correct than the other. Most likely on an x86, the
optimized version will in fact give more accurate results. Of course
predictability may be more important than accuracy, but it is not
helpful to use the word correct in this context.
A properly analyzed Ada floating-point program for example is required
to work correctly whether or not there is extra precision. If the result
is wrong with extra precision, then the program is wrong in the sense
that it is not analyzed with respect to the Ada floating-point model
(which is quite precise).
In fact many floating-point programmers regard fpt as sort of
"incorrect" all the time, and would regard higher precision and
accuracy as always desirable.
So I think it is better to avoid using correct here, it is just a
rhetorical device with no particular content.
The fact of the matter is that there are several inconsistent goals that
you might want to satisfy in a floating-point algorithm:
- Reproducible results independent of optimization. Useful for
debugging and for giving confidence that optimization is not
messing up.
- Maximum accuracy for the calculations performed
- Maximum speed of calculation
- Predictability, you want to know EXACTLY what operations will be'
performed and how the language semantics map onto the hardware, and
by the way, know exactly what the hardware does in all cases (not
true of all machines by any means).
These four criteria are quite different. Note in particular, that
you are identifying correctness with reproducibility, but I think that
most people who would like to use the term would identify it with
predictability, which is a different criterion (predictability
implies reproducibility, but not vice versa).
You surely in fact shift in your use of the term. At first in your
message you are definitely talking about reproducibility (after all this
whole thread was about effects of optimization). But at the end where
you say:
"correctness is the purpose of the computation" I think you must be
talking about predictability.
But of course there are others for whom floating-point arithmetic is
simply an approximation of real arithmetic. With this view, the
computation is never correct, but doing it with maximum precision is at
least the most correct possible.
That's why correctness is a bad term. The purpose of the computation
after all is not correctness, it is to get the right results. Some
notion of correctness (which always must be with respect to a
specification, so you cannot just ignore the language standard, but
rather you need to formally supplement it) may be a means to this
purpose, but it is not the purpose itself.
I think it is quite useful to separate the four criteria here, because
different constituencies have quite different views. A useful compiler
should indeed be able to accomodate all four views, and various useful
balances between them.
Basically you can't have it both ways. Either you are trying to be
pragmatic here, in which case the formal notion of correctness is not a
useful focus, or you are trying to be formal and precise, and you are
interested in a formal notion of correctness. But for that you have to
be a language lawyer, in the sense that correctness can only be shown
with respect to a formal definition, interpreted formally. Yes, the
language definition is often inadequate and must be supplemented, for
example with a schema mapping language semantics to IEEE semantics,
but once supplemented, then you definitely want to be in full language
lawyer mode to make sure that the implementation corresponds to this scheme.
Again I refer you to Sam Figueroa's thesis for a much more extensive
discussion of these issues.
More information about the Gcc
mailing list