Parentheses and compiler optimzation

[spasmous]

If a compiler see's the following statement

c = (a+b)-b

will it optimize it to c=a? I want to force the compiler to evaluate (a
+b) first. Do the parentheses ensure an ANSI conforming compiler HAS
to do that? If not, is there a way?

[Willem]

Re: Parentheses and compiler optimzation

spasmous wrote:
) If a compiler see's the following statement
)
) c = (a+b)-b
)
) will it optimize it to c=a?

It could, yes.

) I want to force the compiler to evaluate (a+b) first.

Why would you want to do that ?

) Do the parentheses ensure an ANSI conforming compiler HAS to do that?

No, I don't think so. The as-if rule and such, you know.

) If not, is there a way?

That depends. What *exactly* do you want to do ?
The result will be the same no matter if the (a+b) is evaluated or not.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Walter Roberson]

Re: Parentheses and compiler optimzation

In article <slrnfvss3r.1te r.willem@snail. stack.nl>,
Willem <willem@stack.n lwrote:

>spasmous wrote:
>) If a compiler see's the following statement

>) c = (a+b)-b

>) will it optimize it to c=a?

>That depends. What *exactly* do you want to do ?
>The result will be the same no matter if the (a+b) is evaluated or not.

Think floating point. If a has a much smaller magnitude than b,
then a+b would evaluate to b; b - b would then evaluate to 0, not a.
Thus for floating point, optimizing (a+b)-b to simply a would give
the "wrong" answer relative to floating point characteristics .

--
"I want to be remembered as the guy who gave his all whenever
he was on the field." -- Walter Payton

[christian.bau]

Re: Parentheses and compiler optimzation

On Apr 10, 8:48 pm, spasmous <spasm...@gmail .comwrote:

If a compiler see's the following statement
>
c = (a+b)-b
>
will it optimize it to c=a? I want to force the compiler to evaluate (a
+b) first. Do the parentheses ensure an ANSI conforming compiler HAS
to do that? If not, is there a way?

The compiler will add a and b, then subtract b. Whether you use
parentheses or not doesn't make any difference at all.

However, there is the "as if" rule: The compiler is allowed to do
_anything_ that is guaranteed to give exactly the same result. For
example, if a and b are both of type unsigned int then it is
guaranteed that (a + b) - b and a give the same result. On the other
hand, if there _is_ a difference between (a + b) - b and a, then the
compiler will _not_ produce a.

[Peter Nilsson]

Re: Parentheses and compiler optimzation

Keith Thompson <ks...@mib.orgw rote:

spasmous <spasm...@gmail .comwrites:

If a compiler see's the following statement

c = (a+b)-b

will it optimize it to c=a?

>
It's likely to to so,

Maybe, maybe not.

though there's no requirement to
perform such an optimization.

There _is_ a requirement that no optimisation
should change the behaviour from the virtual
machine [if there is no unspecified or
undefined behaviour.]

Consider...

int a = -1;
unsigned b = 0;

The expression (a + b) - b has neither the
type nor value of a.

Even if a and b have the same type there can
be problems. See Walter's floating point
example.

--
Peter

[christian.bau]

Re: Parentheses and compiler optimzation

On Apr 11, 3:37 pm, Kenneth Brody <kenbr...@spamc op.netwrote:

I see that my compiler will optimize it away for int, but not for
float.  Where would one find this prohibition in the standard?
>
Mathematically, "(a+b)-b" is the same as "a".  Of course, in this
case, there may be a loss of precision, but does the standard say
that you must preserve loss of precision?  Why doesn't the "as if"
rule apply to floating point?

The C Standard says that (a + b) - b means: Add a and b, subtract b
from the result. Same for integer and floating point. The C Standard
also says that the compiler is allowed to do absolutely anything it
likes, but only as long as the result is exactly what the C Standard
says. So the C Standard doesn't have to say "it's allowed for integer
and not allowed for floating-point". Instead, it is up to the compiler
writer to _prove_ that they produce exactly the same result.

And: "Mathematically " doesn't count. Actually, when you say
"mathematically " you mean "real numbers". Since the C Standard uses
floating-point numbers and not real numbers, it is irrelevant how real
numbers work.

Now an example: How could the compiler optimise this?

double f (int x) { double a = (double) x; double b = 1e300; return
(a + b) - b; }

(And no, it can't replace the return statement with "return a;" but
with something very different!)

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: Parentheses and compiler optimzation

On Fri, 11 Apr 2008 14:35:06 -0700, christian.bau wrote:

Now an example: How could the compiler optimise this?
>
double f (int x) { double a = (double) x; double b = 1e300; return
(a + b) - b; }
>
(And no, it can't replace the return statement with "return a;" but with
something very different!)

Yes, it can replace the return statement with "return a;", unless you
specifically tell it it can't.

6.5p8
"A floating expression may be /contracted/, that is, evaluated as though
it were an atomic operation, thereby omitting rounding errors implied by
the source code and the expression evaluation method. The FP_CONTRACT
pragma in <math.hprovid es a way to disallow contracted expressions.
Otherwise, whether and how expressions are contracted is implementation-
defined."
7.12.2p2
"[...] The default state ("on" or "off") for the pragma is
implementation-defined."

[Anonymous]

Re: Parentheses and compiler optimzation

On Thu, 10 Apr 2008 13:18:42 -0700, Keith Thompson wrote:

spasmous <spasmous@gmail .comwrites:

>If a compiler see's the following statement
>>
>c = (a+b)-b
>>
>will it optimize it to c=a?

<snip>

One obvious way is:
>
tmp = a + b;
c = tmp - b;
>
but the compiler is still free to optimize it down to "c = a;".

Chances are, as soon as the compiler finishes parsing the code and starts
the first stage of compiling, this is already the form it's been reduced
to. As far as optimizations go, this change is most likely a no-op unless
tmp is volatile.

Judicious use of "volatile" might be a solution -- but again, without
knowing the underlying problem, I hesitate to make suggestions.

Correct.