[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
More information about the cfe-dev