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