Re: Implementing Library calls

[Jim Wilson <wilson at specifixinc dot com>]

John Lu wrote:
> I'm working on a port where a long->float conversion is done
> by a library call.  The calling convention requires that the long
> be passed in memory.

You could write a stub function that takes the argument some other way. 
 The stub function can then allocate a stack slot to hold the argument 
to the load->float conversion routine.  Or you could write your own 
load->float conversion routine that doesn't have this problem.

We have code to pre-expand arguments that involve calls, but this 
doesn't work for arguments that make libcalls, since there is no obvious 
call there.  The code for handling libcalls is rather simple, and only 
supports a subset of all calling convention features.

I think there is an underlying assuption here that either a libcall 
takes arguments in registers, or else we don't have 
ACCUMULATE_OUTGOING_ARGS defined.  Without ACCUMULATE_OUTGOING_ARGS, 
each arg is pushed before a call, so there should be no clobbering of 
earlier pushed arguments.

If you can't satisfy either of these, then you need to implement your 
own libcall stub that gets its argument some other way.  There is no 
requirement that libcalls use the same calling convention as regular 
code.  However, if you do go this route, you may not be able to use some 
of the emit_library_call functions, you might have to write your own 
define_expand patterns that emit calls.  See for instance the millicode 
support in the PA port.  This is probably the solution of last resort 
though.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com