[cfe-dev] [llvm-dev] Clang/LLVM function ABI lowering (was: Re: [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM)

David Greene via cfe-dev cfe-dev at lists.llvm.org
Tue Jun 9 13:31:18 PDT 2020

James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes:

> While MLIR may be one part of the solution, I think it's also the case that
> the function-ABI interface between Clang and LLVM is just wrong and should
> be fixed -- independently of whether Clang might use MLIR in the future.


> All that said, an MLIR encoding of the C type system can still be useful --
> it could contain the code which distills the C types into the ABI-specific
> metadata. But, I  see that as less important than getting the fundamentals
> in LLVM-IR into a better shape. Even frontends without a C type system
> representation should still be able to generate LLVM IR which conforms in
> their own manner to the documented ABIs -- without it being super painful.
> Also, the code in Clang now is really confusing, and nearly unmaintainable;
> it would be a clear improvement to be able to eliminate the majority of it,
> not just move it into an MLIR dialect.

+1.  Having had to implement an interface between a proprietary frontend
and LLVM, it's a royal pain.  I've had to do it for three different
targets and each target has its own quirks.  A better frontend->LLVM
interface for ABI concerns would be a huge improvement.  I see moving to
MLIR as pretty orthogonal.  Definitely useful, don't get me wrong, but I
don't want to see that very complex process hold up improvements in the
ABI area.


More information about the cfe-dev mailing list