Re: Subtraction + comparison in one asm instruction?

"Vincent Lefevre" <vincent+news@vinc17.org>
12 Sep 2002 14:24:12 -0400

          From comp.compilers

Related articles
[4 earlier articles]
Re: Subtraction + comparison in one asm instruction? vincent+news@vinc17.org (Vincent Lefevre) (2002-08-23)
Re: Subtraction + comparison in one asm instruction? gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) (2002-09-03)
Re: Subtraction + comparison in one asm instruction? vincent+news@vinc17.org (Vincent Lefevre) (2002-09-08)
Re: Subtraction + comparison in one asm instruction? gdr@integrable-solutions.net (Gabriel Dos Reis) (2002-09-12)
Re: Subtraction + comparison in one asm instruction? vbdis@aol.com (VBDis) (2002-09-12)
Re: Subtraction + comparison in one asm instruction? gdr@integrable-solutions.net (Gabriel Dos Reis) (2002-09-12)
Re: Subtraction + comparison in one asm instruction? vincent+news@vinc17.org (Vincent Lefevre) (2002-09-12)
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)
[2 later articles]
| List of all articles for this month |

From: "Vincent Lefevre" <vincent+news@vinc17.org>
Newsgroups: comp.compilers
Date: 12 Sep 2002 14:24:12 -0400
Organization: a training zoo
References: 02-09-038 02-09-076
Keywords: arithmetic
Posted-Date: 12 Sep 2002 14:24:11 EDT

    VBDis <vbdis@aol.com> wrote:


> IMO the side effects of optimization are unpredictable for
> sub-expressions. Either you expect (x+1-1) being optimized into a
> NOP, what certainly will produce the correct result, or you expect
> that all intermediate steps are executed exactly as given in the
> source code, with no optimizations inside expressions.


It depends on what you mean by correct result. Things you want may be
different if you program in such a way that you can make sure that
there are no overflows or if you assume that the compiler will
generate traps each time there is an overflow, for instance.


But gcc (for instance) currently optimizes x + 1 - 1 to x. So,
under this condition, there is no reason why x - 1 > 0 shouldn't
be optimized to x > 1 (x being a *signed* integer).


> 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
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.


> but the compiler is free to modify and rearrange all the
> /intermediate steps/ which are required to yield that result.


> The substition of (x+1-1) by (x) is an algebraic operation, which
> can be performed before a compiler creates code for that expression,
> and it can be made in the source code as well.


If you can do this, you can also do the subtitution of x-1 > 0 by
x > 1 when x is a signed integer. This subtitution is incorrect for
x unsigned, but anyway x+1-1 -> x is also incorrect if x is a float
or a double. So, you generally need to check the types.


> The conversion of formulas, according to algebraic rules, IMO is
> independent from the ranges of the data types which are used in
> actual source code.


This is wrong (see above).


> Otherwise all the variables, constants and operators in formulas
> must be attributed with explicit rules, which define their intended
> deviation from the common algebraic rules (commutativity,
> associativity...). (I hope to have found the appropriate English
> terms)


Well, I don't understand what you mean.


Vincent Lefèvre.
[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]



Post a followup to this message

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