Hi, On Tue, 24 Nov 2015, Richard Biener wrote:
> On Tue, Nov 24, 2015 at 12:01 AM, Jason Merrill <ja...@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.
