This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Postpone expanding va_arg until pass_stdarg
- From: Michael Matz <matz at suse dot de>
- To: Tom de Vries <Tom_deVries at mentor dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 10 Feb 2015 17:57:50 +0100 (CET)
- Subject: Re: Postpone expanding va_arg until pass_stdarg
- Authentication-results: sourceware.org; auth=none
- References: <54CA6BB1 dot 10502 at mentor dot com> <20150129172535 dot GN1746 at tucnak dot redhat dot com> <54CAB232 dot 1090005 at mentor dot com> <CAFiYyc1XB_6-P32CroiFbE2Of3j3vORu5d7ALuEgoN8F9yk0Tg at mail dot gmail dot com> <54CB61C8 dot 4060801 at mentor dot com> <alpine dot LNX dot 2 dot 00 dot 1501301322400 dot 18611 at wotan dot suse dot de> <54CF8AB8 dot 5040405 at mentor dot com> <alpine dot LNX dot 2 dot 00 dot 1502021628300 dot 18611 at wotan dot suse dot de> <54D0979A dot 8030200 at mentor dot com> <alpine dot LNX dot 2 dot 00 dot 1502031434250 dot 18611 at wotan dot suse dot de> <54D9CDE9 dot 8010805 at mentor dot com>
Hi,
On Tue, 10 Feb 2015, Tom de Vries wrote:
> I've added two modifications to gimplify_modify_expr:
> - the WITH_SIZE_EXPR in which the CALL_TREE is wrapped, is dropped after
> gimplification, but we need the size expression at expansion in pass_stdarg.
> So I added the size expression as argument to the internal function.
> [ And at pass_stdarg::execute, we wrap the result of
> gimplify_va_arg_internal
> in a WITH_SIZE_EXPR before generating the assign to the lhs ]
Hmm, why do you need the WITH_SIZE_EXPR actually? For variable-sized
types returned by va_arg?
> - we detect after gimplify_arg (&ap) whether it created a copy ap.1 of ap,
> rather than use ap itself, and if so, we copy the value back from ap.1 to ap
> after va_arg.
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).
> 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.
Ciao,
Michael.