This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 25/11/15 15:47, Michael Matz wrote:
> 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).
> 

That is all true - but if you have to pick an order that makes sense to
users, especially of functions that are not varargs (i.e., most
functions), then left-to-right is the only logical, natural order - at
least for those of use who use left-to-right languages.

How often would left-to-right evaluation actually cause efficiency
problems?  It would only be for functions that take a lot of parameters
or a variable number of parameters, and then only when calling them with
arguments that are calculated in a way that might have side-effects
(otherwise the compiler is free to re-order them anyway).  Is that
really going to be a big issue?  One should not limit the language just
because of a tiny efficiency issue with rarely-used cases.


(The other orderings discussed in the proposal seem fair enough - it is
only function parameter ordering that is an issue, I think.)





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]