[llvm-dev] [RFC] Introducing an explicit calling convention (original) (raw)

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

More information about the llvm-dev mailing list