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