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

[Frej Drejhammar via llvm-dev]

Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> writes:

> 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 understand and support the desire for having a declarative way to
describe calling conventions but remember that the original proposal is
only for the callee-side of the calling convention. Its intended use is
for producing code which slots into, for example the shadow of a
stackmap or a manually analyzed binary. In this case, the assignment of
values to registers has already been done by something else, that is why
the proposal does not cover calls. Normally the user is responsible for
both the arguments to the stackmap intrinsics and building the function
called from its shadow. So matching up registers to types is in practice
not a problem.

> 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.

That's a good suggestion. Right now our prototype just uses raw register
numbers (it was first made when llvm.read_register used a raw register
number), switching to string attributes will probably make the patch
less intrusive.

--Frej