Re: C++ order of evaluation of operands, arguments

[Michael Matz <matz at suse dot de>]

Hi,

On Tue, 24 Nov 2015, Richard Biener wrote:

> On Tue, Nov 24, 2015 at 12:01 AM, Jason Merrill <jason@redhat.com> wrote:
> > There's a proposal working through the C++ committee to define the order of
> > evaluation of subexpressions that previously had unspecified ordering:
> >
> > http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
> >
> > I agree with much of this, but was concerned about the proposal to define
> > order of evaluation of function arguments as left-to-right, since GCC does
> > right-to-left on PUSH_ARGS_REVERSED targets, including x86_64.

Actually the most natural order for an (normal, stack-passing) 
implementation that supports varargs is right-to-left, so the proposal has 
it exactly backwards.  (Reason being that named arguments then have 
constant offsets from stack pointer).

right-to-left is also the better order for all ABIs that pass (at least 
some) arguments on stack but give left arguments smaller offsets from 
top-of-stack (as most ABIs do).

> The reason we have PUSH_ARGS_REVERSED is to get more optimal
> code generation for calls reducing lifetime of argument computation
> results.  Like when you have
> 
>  foo (bar(), baz())
> 
> then generate
> 
>   reg = bar();
>   push reg;
>   reg = baz();
>   push reg;
>   foo ();
> 
> instead of
> 
>   reg = baz();
>   spill reg;
>   reg = bar();
>   push reg;
>   push spilled reg;
>   foo ();

Your examples are switched, but the idea is the correct one (result of bar 
needs to be pushed last in the x86 ABI).

> I would like to get rid of PUSH_ARGS_REVERSED (as used in 
> gimplification) because it's also one source of very early IL 
> differences across archs.

Actually most other targets should also act as if PUSH_ARGS_REVERSED, not 
only x86_64.


Ciao,
Michael.