Re: Order of function evaluation

From: Glen Herrmannsfeldt (gah_at_ugcs.caltech.edu)
Date: 10/25/03 

Date: Sat, 25 Oct 2003 01:19:22 GMT

"Sheldon Simms" <sheldonsimms@yahoo.com> wrote in message
news:pan.2003.10.25.00.22.19.527576@yahoo.com...
> On Fri, 24 Oct 2003 23:41:34 +0000, Jens.Toerring wrote:
>
> > I have a possibly rather stupid question about the order of evaluation
> > in a statement like this:
> >
> > result = foo( x ) - bar( y );
> >
> > How can I make 100% sure that foo(x) is evaluated before bar(y), where
> > foo() and bar() can be either functions or macros?

(snip)

> In the first case, there is only one sequence point at the end of the
> single line and since the compiler doesn't actually have to complete
> any side effects until then, it is free to rearrange the evaluation
> of foo() and bar().
>
> Some refs:
>
> 5.1.2.3 Program execution
> 2 Accessing a volatile object, modifying an object, modifying a
> file, or calling a function that does any of those operations
> are all side effects, which are changes in the state of the
> execution environment. Evaluation of an expression may produce
> side effects. At certain specified points in the execution
> sequence called sequence points, all side effects of previous
> evaluations shall be complete and no side effects of subsequent
> evaluations shall have taken place.

I am not at all sure what optimizers are allowed to do. At least in Fortran
there once was a traditional optimization of moving invariant expressions
out of loops. Though doing that for function calls can sometimes cause
problems.

One favorite example from Fortran, but translated to C goes something like:

for(i=0;i<n;i++) {
   if(a>0) b[i] *= sqrt(a);
   c[i] *= a;
   }

There were compilers that would evaluate sqrt(a) outside the loop, keep the
result in a register and use it in the multiply.

Function calls don't tend to allow that optimization in general, though. I
believe that C compilers can still do common subexpression elimination,
except in the case of volatile variables.

-- glen

Relevant Pages

  • Re: m4 Problems
    ... The trick is to avoid evaluation of the two conditional parts by quoting ... them at least ONE level more than the enclosing ifdef(). ... will still evaluate `foo' and `bar' at the outter level, ...
    (freebsd-questions)
  • Re: Order of function evaluation
    ... > I have a possibly rather stupid question about the order of evaluation ... Suppose that foo and bar are defined this way: ... Cases like these are why we have the 'volatile' qualifier. ...
    (comp.lang.c)
  • Re: Order of function evaluation
    ... >with this when writing some hardware-related stuff where foo() and bar() ... >are functions or macros (I want to make sure the solution is independent ... pure functions and without such assumptions the order of evaluation cannot ...
    (comp.lang.c)
  • Re: Beginner post-increment question
    ... So, for example, a compiler could legally translate: ... break it down into several statements, with one evaluation per statement. ... if foo() and bar() each produced output as well as returning ...
    (comp.lang.c)
  • Re: Order of function evaluation
    ... >> I have a possibly rather stupid question about the order of evaluation ... > of foo() and bar(). ... Function calls don't tend to allow that optimization in general, ...
    (comp.lang.c)