Re: Your assign_parms changes

Re: Your assign_parms changes

[Richard Kenner]

    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.  

Right, I understand that, but then why the second change to prohibit this
from being done for CONCAT, which seems a very valuable case?

    I guess we need to update max_parm_reg appropriately when we
    allocate the new reg to operate as a parm within the function.

Most certainly.  And also the parm stack location.

Re: Your assign_parms changes

[David Edelsohn]

>>>>> Richard Kenner writes:

Richard> Right, I understand that, but then why the second change to prohibit this
Richard> from being done for CONCAT, which seems a very valuable case?

	See the discussion thread started by Eric Botcazou:

http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00031.html

The CONCAT generated for complex parameters produced additional spilling
and worse code.

David

Re: Your assign_parms changes

[David Edelsohn]

>>>>> 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

Your assign_parms changes

[Richard Kenner]

On closer look, that's the only one that causes problems with max_parm_reg.

But I don't understand either of them.

The first change (revision 1.469) seems fine: you can store the group even 
if it's a CONCAT, at least I think so.  So I don't understand the second
change (1.472).  But the real problem appears to be that you set DECL_RTL
of a PARM_DECL to a REG (or CONCAT) but never update max_parm_regs.

See my last message for more.