This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should -fcross-jumping be part of -O1?


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.






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]