Re: question about REG_PARM_STACK_SPACE usage in expand_call

[Jeff Law <law at redhat dot com>]

On 12/14/13 13:14, Tom de Vries wrote:
> I wonder if OUTGOING_REG_PARM_STACK_SPACE makes a difference here.
If I'm reading the archives correctly is the caller/callee may have 
different ABIs (by way of sysv/ms_abi attributes).  Presumably there's 
some magic to deal with the differences in the ABIs to make that work.

So, at least in theory you could have a caller/callee which differ 
materially in OUTGOING_REG_PARM_STACK_SPACE (in particular I'd be 
worried anytime the caller's value is less than the callee's value.





> If OUTGOING_REG_PARM_STACK_SPACE == 0, it is the responsibility of the
> callee to allocate the area reserved for arguments passed in registers.
> AFAIU, both functions a and b would do that in their own stack frame,
> and there's no need to test for reg_parm_stack_space !=
> REG_PARM_STACK_SPACE (current_function_decl).
Seems reasonable.  I probably came to similar conclusions when I first 
wrote the tail/sibling call stuff.  I'd certainly want to hear from Jan 
and/or Kai since they added the change and presumably would have some 
state on exactly what these cross-abi calls can do.

> If OUTGOING_REG_PARM_STACK_SPACE != 0, it is the responsibility of the
> caller to allocate the area reserved for arguments passed in registers.
> Which means that function a and b share the space allocated by the
> caller of function a.
> AFAIU, what is required is reg_parm_stack_space <= REG_PARM_STACK_SPACE
> (current_function_decl).
>
> So this might be a more precise fix:
[ ... ]
> ...
>
> But probably not a stage3 fix.
Agreed on both statements.

jeff