Postpone expanding va_arg until pass_stdarg

[Michael Matz]

Hi,

On Wed, 11 Feb 2015, Tom de Vries wrote:

> > My idea was to not generate temporaries and hence copies for 
> > non-scalar types, but rather construct the "result" of va_arg directly 
> > into the original LHS (that would then also trivially solve the 
> > problem of nno-copyable types).
> 
> The copy mentioned here is of ap, not of the result of va_arg.

Whoops, I misread, yes.  Thanks.

> > > I'm not really sure yet why std_gimplify_va_arg_expr has a part
> > > commented out. Michael, can you comment?
> > 
> > I think I did that because of SSA form.  The old sequence calculated
> > 
> >    vatmp = valist;
> >    vatmp = vatmp + boundary-1
> >    vatmp = vatmp & -boundary
> > 
> > (where the local variable in that function 'valist_tmp' is the tree
> > VAR_DECL 'vatmp') and then continue to use valist_tmp.  When in SSA form
> > the gimplifier will rewrite this into:
> > 
> >    vatmp_1 = valist;
> >    vatmp_2 = vatmp_1 + boundary-1
> >    vatmp_3 = vatmp_2 & -boundary
> > 
> > but the local valist_tmp variable will continue to be the VAR_DECL, not
> > the vatmp_3 ssa name.  Basically whenever one gimplifies a MODIFY_EXPR
> > while in SSA form it's suspicious.  So the new code simply build the
> > expression:
> > 
> >    ((valist + bound-1) & -bound)
> > 
> > gimplifies that into an rvalue (most probably an SSA name) and uses that
> > to go on generating code by making valist_tmp be that returned rvalue.
> > 
> > I think you'll find that removing that code will make the SSA verifier
> > scream or generate invalid code with -m32 when that hook is used.
> > 
> 
> Thanks for the detailed explanation. I'm not sure I understand the 
> problem well enough, so I'll try to trigger it and investigate.

Actually the above fails to mention what the real problem is :-)  The 
problem is that the local variable valist_tmp will be used to generate 
further code after the above expression is generated.  Without my patch it 
will continue to point to the VAR_DECL, not to the SSA name that actually 
holds the computed value in the generated code.


Ciao,
Michael.