Re: Enforcing order of execution for function arguments

[Roberto COSTA <roberto dot costa at st dot com>]

Andrew Haley wrote:
> Roberto COSTA writes:
>  > Andrew Haley wrote:
>  > > Chris Jefferson writes:
>  > > 
>  > >  > One thing which comes up regularly in various C and C++
>  > >  > messageboards is that statements like "f() + g()" and "a(f(), g())"
>  > >  > do not declare which order f() and g() will be executed in.
>  > >  > 
>  > >  > How hard would it be to fix the order of execution in gcc/g++?
>  > >  > Could someone point me to the piece of code which must change, or
>  > >  > if it is only a very small change, the actual change required? I
>  > >  > would very much like to be able to benchmark this, as I can find no
>  > >  > previous case where someone has tried fixing the order of execution
>  > >  > to see if it actually makes any measureable difference.
>  > > 
>  > > The easiest way is during gimplification: you'd walk over the arglist
>  > > from left to right, calling
>  > > 
>  > >         gimplify_expr (&arg, pre_p, post_p,
>  > > 		       is_gimple_formal_tmp_var, fb_rvalue);
>  > > 
>  > > on each arg.
>  > 
>  > But would it be sufficient?
>
> I think so.
>
>  > I guess you would also have to make sure that further passes (i.e. 
>  > out-of-ssa) do not revert what you have just done.
>
> If any arg had side-effects that would be a bug.

Actually, I was thinking about the case "g(a(), b());".
Let's imagine the gimplified code (because of your change) looks like:

t1 = a();
t2 = b();
g(t1, t2);

Are we always sure that t1 and t2 will not be pushed again in the 
CALL_EXPR by further transformations?

Roberto