[llvm-dev] [RFC] Introducing an explicit calling convention
Manuel Jacob via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 15 13:56:23 PST 2019
[+CC Kai Nacke, who I remember talking about this topic at a FOSDEM 2014
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
>> 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
> 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?
More information about the llvm-dev