[Freeciv-Dev] Re: (PR#7279) Macro optimizations

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >


   int i = 0;
   printf("%d, %d, %d", i++ i++ i++);

   // f() depends on and/or changes global data
   printf("%d, %d, %d", f(), f(), f());

or something more complex along these lines would be the case. One is
as likely to see 2 1 0 as 0 1 2 in a random compiler according to what
order it chose to push arguments on the stack, and maybe what order it
thought best to generate the data to push in more complex operations.


The key thing is that what looks to be the same function with identical
args may or may not produce the same value when inline hints are used
since it is indeterminate whether one actually does an inline or does an
out-of-line call and the two may produce different results.

Inline is just a hint to the compiler like "register". It doesn't mean
it will happen which is one reason why inline can at best approach the
optimization efficiency of something guaranteed like macros. The arg order
just reflects that different parts of the compiler are doing things and
they don't have to agree even within the same compiler.

There are all sorts of issues like this with inlining, thus it is almost
never used in good "C" code since there are other techniques that are both
more efficient and guaranteed to do what one expects by looking at the
code.

Cheers,
RossW
=====

Arnstein Lindgard wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >
> 
> On Tue, 20 Jan 2004 17:10:39 -0800 rwetmore@xxxxxxxxxxxx wrote:
> 
> 
>>Some interesting comments on inline functions from Stroustrup.
>>
>>   The order of evaluation of actual arguments to functions is undefined.
>>   In particular, an inline expansion is not required to preserve the
>>   order of evaluation of actual arguments that the implementation would
>>   have produced for an out-of-line call. Since one call of a function in a
>>   program may be inlined while another is handled by the normal function
>>   call mechanism, this can lead to two calls to the same function with
>>   identical actual arguments yielding different results.
> 
> Can the order of evaluation of function arguments really be relevant?
> 
> Arnstein