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

[Reid Kleckner via llvm-dev]

On Tue, Jan 15, 2019 at 9:24 AM David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > 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...
>
> +1.  Coordinating ABI semantics between the frontend and LLVM is tricky.
> It would be super helpful to have a formal way of expressing ABI
> semantics in the IR.
>

I agree with that, but I think most users want LLVM to go the other way
from what the OP is suggesting. I think non-clang frontends would prefer it
if we pushed more calling convention details down into LLVM, not the other
way around.

Regarding the original proposal, sure, we could probably support a calling
convention that explicitly assigns arguments to same-sized registers. But I
doubt that it will ever be expressive enough to handle the corner cases of
HVA and struct passing. Those are the areas where other frontends typically
run into ABI compatibility problems. So, we can definitely add a convention
that explicitly assigns registers, but we should document that it's really
only going to handle the easy cases of assigning register-sized arguments
to appropriately sized registers.

I suggest that the convention use string attributes, instead of attributes
that point to metadata. We don't have any facilities to allow attributes to
point to metadata, but we already support string attributes on functions,
and it should be easy to extend the IR parsing to support an argument
attribute that looks like `hwreg("rax,rdx")`. I don't think it will impact
bitcode serialization, but I could be wrong. For the list of CSRs, you can
add an attribute like `"calleesavedregs"="rbx,rcx"` to the function's
attribute set. That won't require any bitcode or IR parser modifications.

Hope that helps!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/3ad7a00a/attachment.html>