[clang] [Clang][CodeGen][CIR][NFC] Refactor CGCXXABI classes for code sharing (PR #165078)

John McCall via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 28 11:37:42 PDT 2025


rjmccall wrote:

Okay, just for clarity, CIR codegen is the lowering from CIR to LLVM dialect MLIR, right?

This is exactly the code that I would very strongly like to avoid duplicating between the existing CodeGen and the CIR CodeGen. While I appreciate that this PR is trying to extract all of the logic and just leave actual instruction emission for IR-specific code, I do not think this is sufficiently avoiding code duplication: the structure of the IR-specific code, knowing which calls to make and which instructions to emit, necessarily represents a lot of logic that must be duplicated. And since the information content and structure of LLVM IR and LLVM-dialect MLIR are by definition isomorphic, this duplication is essentially unnecessary — at no point in the process should we ever be making different choices based on the output IR.

I think there are two reasonable paths forward here:
1. Accept just outputting LLVM IR from CIR CodeGen. If CIR clients need LLVM-dialect MLIR, they will need to transform it back.
2. Find some way to fully share the IR-generic code between target IRs, either by boxing or using templates.

I have a strong preference for doing (1) in the medium term, while we're bringing up CIR CodeGen, and then tackling (2) once we've got a functional system written on top of input-generic logic. Trying to simultaneously make the logic input-generic and output-generic is going to greatly complicate the refactor and drag the entire process out.

I understand that (1) interferes with the ability to do mixed-dialect MLIR lowerings where non-CIR operations are preserved in the output. However, I have not heard of there being an immediate need for that; it seems like CIR clients all want to do an arbitrary transforms (serializations, etc.) on CIR and then ultimately lower it to something in LLVM dialect. Also, it's still tractable to do this, it's just less efficient: you would just need to emit IR for an individual operation into a temporary LLVM function, raise that function into LLVM-dialect MLIR, and then splice that into your output.

https://github.com/llvm/llvm-project/pull/165078


More information about the cfe-commits mailing list