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. > > 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
