Re: The nvptx port [7/11+] Inform the port about call arguments

[Jeff Law <law at redhat dot com>]

On 10/21/14 21:29, Bernd Schmidt wrote:
> A normal call looks like
>
> {
>    .param.u32 %retval_in;
>    .param.u64 %out_arg0;
>    st.param.u64 [%out_arg0], %r1400;
>    call (%retval_in), PopCnt, (%out_arg0);
>    ld.param.u32    %r1403, [%retval_in];
> }
>
> which declares local variables for the args and return value, stores the
> pseudos in the outgoing args, calls the function with explicitly named
> args and return values, and loads the incoming return value. All this is
> produced by nvptx_output_call_insn for a single CALL rtx insn.
So far, so good.

> Indirect calls additionally need to produce a .callprototype pseudo-op
> which looks like a function declaration; for normal calls the called
> function must already be declared elsewhere. The machinery to produce
> such .callprototypes is also used to produce a ptx decl from the call
> insn for an external K&R declaration with no argument types.
Yea, no surprise here.


> Couple of problems with this - the fusage isn't available to gen_call,
> it gets added to the call insn after it is emitted, but the backend
> would like to have this information when emitting the insn.
Right.  Targets which have needed this emit the decorations at 
insn-output time so the fusage has been attached.


> Also, I'd
> need the order to be reliable and I don't think CALL_INSN_FUNCTION_USAGE
> is really designed to guarantee that (I suspect the order of register
> args and things like the struct return reg is wrong). I also need the
> exact function type and the call_args hook seems like the easiest way to
> communicate it to the backend.
We've depended on the ordering in the PA, well, forever.  However, I 
doubt ordering of regs in the fusage is documented at all!  We could 
change that.

So, in the end I'm torn.  I don't like adding new hooks when they're not 
needed, but I have some reservations about relying on the order of stuff 
in CALL_INSN_FUNCTION_USAGE and I worry a bit that you might end up with 
stuff other than arguments on that list -- the PA port could filter on 
the hard registers used for passing arguments, so other stuff appearing 
isn't a big deal.

Let me sleep on this one :-)
Jeff