On 10/21/2014 11:11 PM, Jeff Law wrote:
On 10/20/14 14:29, Bernd Schmidt wrote:
In ptx assembly we need to decorate call insns with the arguments that
are being passed. We also need to know the exact function type. This is
kind of hard to do with the existing infrastructure since things like
function_arg are called at other times rather than just when emitting a
call, so this patch adds two more hooks, one called just before argument
registers are loaded (once for each arg), and the other just after the
call is complete.
How exactly do you need to decorate? Just mention the register, size
information or do you need full type information?
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.
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.
We've had targets where we had to indicate register banks for each
argument. Those would walk CALL_INSN_FUNCTION_USAGE to find the
argument registers, then from the register # we would know which
register bank to use. Would that work for you?
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. 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.
Bernd
