On Mon, Feb 4, 2013 at 10:31 AM, Yuri Rumyantsev <ysrum...@gmail.com> wrote:
> Hi Ian,
>
> It looks that i had to formulate my notes more precisely - the issue
> with which one our customer met is that there are plenty calls of C++
> functions with member class function arguments for which an order of
> call is essential (see e.g. attached testy-case on C that emulates it.
> So I only care about an order of calls in incoming arguments.
Even though I agree with Ian let me suggest sth. The order of side-effects
when evaluating function call arguments is currently determined by the
order we gimplify, thus solely by gimplify.c. Your patch changes behavior
in multiple places of the compiler, which is not acceptable. Instead
of changing the default order with a switch the only thing I would view
as possibly acceptable is to have a
-ffunction-call-argument-evaluation-order={left-to-right,right-to-left,undefined}
where 'undefined' would be the default. I'm not sure if we can guarantee
the order of evaluation of side-effects in that simple manner though.
Richard.
> Yuri.
>
> 2013/2/1 Ian Lance Taylor <i...@google.com>:
>> On Fri, Feb 1, 2013 at 5:10 AM, Yuri Rumyantsev <ysrum...@gmail.com> wrote:
>>>
>>> This is simple fix that is aimed to help users in porting their
>>> applications to x86 platforms which rely on an order of function
>>> argument evaluation. To preserve direct order of argument evaluation
>>> they need to be added additional option '-mno-push-args' to compile
>>> that looks reasonable price for non-C/C++ Standard conformance.
>>> I checked that adding this option does not affect on performance on
>>> Corei7 and Atom platforms. Note also that option "-push-args" is
>>> passed by default on all x86 platforms and it means that changing this
>>> macros will not likely affect on almost all gcc users.
>>
>> If your goal is to preserve the order in which function arguments are
>> evaluated, this patch is not going to be reliable. It only affects
>> the conversion from GIMPLE to RTL. The GIMPLE optimizers will have
>> already had plenty of opportunity to change the function argument
>> evaluation order.
>>
>> I don't think we should change the compiler to generate less efficient
>> code in order to help non-standard-conforming programs when the change
>> won't work reliably anyhow.
>>
>> Ian
