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