Re: Subtraction + comparison in one asm instruction?

Vincent Lefevre <vincent+news@vinc17.org> wrote:
>> Optimized code must produce the same /results/ as non-optimized code,
>
> No, I completely disagree. This is not true in practice and will
> probably never be true, in particular for floating-point (some


Well, then you obviously have never worked with anything where getting
the same result repoeatably for the same results is absolutely crucial.
And one should not have to turn off optimisations to get well-defined
results.


> processors use extended precision internally, and depending on the
> optimizations, you'll get different results, but all are conform to
> the standard) and undefined behavior. If you want your code to produce
> the same results with and without optimizations, it's up to you to
> write code in some way to ensure that and/or use compiler switches to
> disable some optimizations.


NO - this should be the opposite - there should be flags that turn
such behaviour on for the extremely foolhardy and clueless and
those who know the difference wouldn't matter.


> Vincent Lefevre.
> [This is an ancient sore point. In the IBM Fortran X compiler about
> 30 years ago, the guy working on optimization set as a ground rule for
> himself that any new code an optimization generated had to produce
> bit-identical results to the old code, and he managed to get some pretty
> amazing results anyway. But in general I concur that any code that
> meets the language spec is valid, regardless of whether the results
> are identical to some other code that also meets the language spec.
> -John]
>


But more often than not, various "this is safe optimisation, even if the
result is not bit identical" optimisations then gets applied to something
that makes the "not bit identical"ness to scale up really fast ...


--
Sander
[I wouldn't disagree. I think the problem is that languages have too
often been defined with more thought about making optimizations possible
than to making numerical results good. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.