This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Your assign_parms changes
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner), Fariborz Jahanian <fjahanian at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 17 Dec 2003 20:55:43 -0500
- Subject: Re: Your assign_parms changes
- References: <10312180010.AA07225@vlsi1.ultra.nyu.edu>
>>>>> Richard Kenner writes:
Richard> On closer look, that's the only one that causes problems with max_parm_reg.
Richard> But I don't understand either of them.
Richard> The first change (revision 1.469) seems fine: you can store the group even
Richard> if it's a CONCAT, at least I think so. So I don't understand the second
Richard> change (1.472). But the real problem appears to be that you set DECL_RTL
Richard> of a PARM_DECL to a REG (or CONCAT) but never update max_parm_regs.
After reading the comments in the function, the mailinglist
archive can help shed more light on the patch, the authors of the patch
and the motivation for the patch.
The patch is trying to prevent GCC from pessimizing code generated
for argument passing when the word size within the function is larger than
the word size specified in the ABI for argument passing. For example,
passing a 64-bit long long int in two GPRs (each treated as 32-bits wide),
but utilizing 64-bit GPRs and 64-bit computation within the function. If
the parameter is passed in two GPRs, GCC can form the 64-bit quantity
using register operations instead of using stack memory as an intermediate
location to concatenate the pieces.
I guess we need to update max_parm_reg appropriately when we
allocate the new reg to operate as a parm within the function.
David