This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]