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.
