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