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

[Richard Biener <richard dot guenther at gmail dot com>]

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.
>
> Any thoughts?

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 ();

where GCC cannot re-order baz() and bar() later because the undefined evaluation
order isn't exposed in the IL.

Of course this matters most to archs that pass arguments via the stack.  And it
doesn't work in the case above because we don't interleave argument setup
of foo () with the calls.

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.

But because of the above idea the effects on code generation may be visible.

As x86_64 is affected investigating the effects on it (and i?86 for the stack
passing case) would be a start.

Of course in the end the frontend should be responsible for enforcing proper
evaluation order of side-effects in arguments so PUSH_ARGS_REVERSED
might still do all the important parts of getting better argument
setup for calls.

Richard.

> Jason