[llvm-dev] [RFC] Introducing an explicit calling convention

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 15 03:21:17 PST 2019


On 15/01/2019 08:20, Frej Drejhammar via llvm-dev wrote:
> Only parameters passed in registers are considered as the
> llvm.addressofreturnaddress intrinsic can be used to calculate the
> location of values on the callers stack.

I'm not convinced by this part of the proposal.  It is valid for x86, 
for calls that use a normal call instruction and so the return address 
is pushed onto the stack, but on pretty much any other architecture this 
is not the case: the return address is in a register and it's the 
responsibility of the callee prolog to spill it  (or to not spill it, if 
this is a leaf function), so may well not be at the start of the return 
area.  It's also unlikely to interact well with safe stack and similar 
techniques.

Perhaps more importantly, this works only for calling conventions where 
the caller is responsible for cleaning up the stack.  Some calling 
conventions (e.g. Windows' stdcall) require the callee to clean up the 
stack, supporting these would require that we be able to find on-stack 
parameters and move the stack pointer from IR.

Supporting any of these probably requires more explicit prolog and 
epilog instructions in the IR.

I'm not opposed to this in principle, and actually I'd quite like to 
move in this direction and remove our reliance on undocumented and 
inconsistent conventions between the back end and the front end for 
conveying information about ABIs.  For example, returning two 32-bit 
integers or a pair of pointers on x86-32 requires returning the result 
in a single i64 in LLVM IR (on platforms where small structs are 
returned in registers, not on Linux), which is not particularly helpful 
for analysis or consistent with any other architecture.  Given that 
front ends have to be aware of calling conventions, it would be nice if 
they could express them in the same way that the ABI references do...

David


More information about the llvm-dev mailing list