Re: Order of argument evaluation in C++, etc.

I'm surprises that David Chase isn't familiar with compilers which
take advantage of the permission to evaluate arguments in arbitrary
order in order to generate better code. The basic idea is that if
you need to generate code for two subexpressions, you want to generate
code for the more complex subexpression first. Why? Because after
you evaluate a subexpression, you have to keep its value around in a
register (unless you want to pay the cost of writing it to memory).
Therefore, after you evaluate one of the subexpressions you have one
fewer register available to evaluate the second one. This idea is
not new; the first two compilers for C (the Ritchie compiler and PCC)
both used it.


Consider the following code:


void subr(int x) {
        extern int ival;
        extern void g(int, int);
        extern int h(int); /* might modify ival */


        g(ival, h(x));
}


On most machines the call to "h" will require more registers than
evaluating "ival", so that calling "h" first will result in optimal
code (assuming we rule out interprocedural optimizations). In fact
the following C compilers will all call "h" before evaluating "ival"
(and do so even if the order of the arguments to "g" is reversed):


HP PA-RISC: HPUX 9.0
HP PA-RISC: GCC 2.6.3
MIPS R3000: SVR4
SUN SPARC: SunOS 4.1.1


Curiously enough, GCC for the SPARC loads "ival" into a register
before calling "h". The code it generates is still optimal because
the SPARC call mechanism automatically makes a new register window
available, so minimizing register usage is not necessary. On the
other machines there are no register windows, and any registers used
by a procedure must be explicitly saved and stored by that procedure.


So in the absence of register windows (which seem to have fallen out
of favor) requiring left-to-right evaluation will force a compiler
to generate non-optimal code for the above example. This does not
answer David Chase's request for quantitative measurements:


> so far the only one I've seen has been from Will
> Clinger, describing Scheme/Lisp optimization (7.5% code size reduction).
> Yet, your claim has been dogma since before Scheme even existed. Surely,
> in all that time, someone MUST have measured the benefit.


As I understand it, the dogma is the result of experience implementing
Algol 60. Both computer hardware and compiler technology have changed
significantly since then, which makes the value of any studies conducted
at that time open to question even if they were valid when conducted.
Kenneth Almquist
[Seems to me that many calling sequences store arguments in places that don't
affect the expression register count. PCC and the Ritchie compiler
certainly did. -John]
--

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