Re: Subtraction + comparison in one asm instruction?

"Sander Vesik" <sander@haldjas.folklore.ee>
12 Nov 2002 14:07:09 -0500

          From comp.compilers

Related articles
[11 earlier articles]
Re: Subtraction + comparison in one asm instruction? anton@mips.complang.tuwien.ac.at (Anton Ertl) (2002-09-14)
Re: Subtraction + comparison in one asm instruction? vincent+news@vinc17.org (Vincent Lefevre) (2002-09-14)
Re: Subtraction + comparison in one asm instruction? vbdis@aol.com (VBDis) (2002-09-19)
Re: Subtraction + comparison in one asm instruction? anton@mips.complang.tuwien.ac.at (Anton Ertl) (2002-09-19)
Re: Subtraction + comparison in one asm instruction? joachim_d@gmx.de (Joachim Durchholz) (2002-09-19)
Re: Subtraction + comparison in one asm instruction? sander@haldjas.folklore.ee (Sander Vesik) (2002-11-12)
Re: Subtraction + comparison in one asm instruction? sander@haldjas.folklore.ee (Sander Vesik) (2002-11-12)
Re: Subtraction + comparison in one asm instruction? jvorbrueggen@mediasec.de (Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=) (2002-11-13)
| List of all articles for this month |

From: "Sander Vesik" <sander@haldjas.folklore.ee>
Newsgroups: comp.compilers
Date: 12 Nov 2002 14:07:09 -0500
Organization: ERA/EKI FO
References: 02-09-038 02-09-076 02-09-083
Keywords: arithmetic, optimize, comment
Posted-Date: 12 Nov 2002 14:07:09 EST

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]


Post a followup to this message

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