[llvm-dev] [RFC] Introducing an explicit calling convention (original) (raw)

Frej Drejhammar via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 16 03:44:24 PST 2019

David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:

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: [...]

You're right, that only works for x86. A cleaner way would be to require that if the stackpointer is associated with a parameter, the value of that parameter should be the caller's stackpointer. The explicit CC would then have to take this into account while producing its prologue, but that shouldn't be worse than what we are already doing on return [see below].

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.

In our prototype implementation, used for an Erlang JIT, we have call chains (not tail calls) of explicitcc functions where the leaf does a direct return back to the initial call. For that we have implemented a stack-adjustment function attribute which allows us to adjust the stack pointer on return (from the stackmap we know the size of each activation record on the stack and our runtime system knows the call tree).

--Frej

More information about the llvm-dev mailing list