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

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.

                           -David

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>

Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> writes:
>     +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.
That would be great, but I'm not even sure how it would be possible
given the multitude of frontend languages and their ABI expectations.
Wouldn't we have to carry quite a lot of language semantic information
around?  For example, AFAIK right now LLVM can't distinguish between an
ordinary struct containing two doubles and double complex.  The various
vector ABIs may treat those two types differently, for example.

                        -David

[+CC Kai Nacke, who I remember talking about this topic at a FOSDEM 2014 
talk]

On 2019-01-15 19:14, Reid Kleckner via llvm-dev wrote:
> 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.
I agree that handling the calling conventions in one place (e.g. the 
frontend) would be a good idea.

Sometimes people complain that ABI handling in the frontend is hard and 
that they have to duplicate (in their language’s frontend) what Clang 
does.  However, I don’t think that pushing more of this complexity into 
LLVM would be a good idea.  What I suggest is that there should be a 
helper library for ABI lowering (ideally that library should be used by 
Clang eventually).  What do you think?

-Manuel

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