Hi Richard,
We wrote:
> Your patch changes behavior
> in multiple places of the compiler, which is not acceptable.
I don't change behavior of compiler since option "-mpush-args" is
passed to compiler by default. We do change compiler behavior if only
option "-mno-push-args" was passed to compiler explicitly.
Best regards.
Yuri.
2013/2/4 Richard Biener <richard.guent...@gmail.com>:
> 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
