This is the mail archive of the
mailing list for the GCC project.
Re: The nvptx port [7/11+] Inform the port about call arguments
- From: Jeff Law <law at redhat dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 21 Oct 2014 21:53:17 +0000
- Subject: Re: The nvptx port [7/11+] Inform the port about call arguments
- Authentication-results: sourceware.org; auth=none
- References: <54451994 dot 9070209 at codesourcery dot com> <54451C57 dot 5020705 at codesourcery dot com> <5446CC00 dot 9000009 at redhat dot com> <5446D037 dot 8030607 at codesourcery dot com>
On 10/21/14 21:29, Bernd Schmidt wrote:
A normal call looks like
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.
Right. Targets which have needed this emit the decorations at
insn-output time so the fusage has been attached.
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.
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
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.
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 :-)