Discussion Summary
Thank you to everybody who has provided feedback so far!
We found strong consensus in the community that a ClangIR will be a large improvement to clang and that it should exhibit some crucial features:
- Be part of the regular compiler pipeline flow: support both static analysis and codegen from day one.
- Live in Clang rather than MLIR.
- Avoid regressing compile time, memory consumption and binary size – tracking those as early as possible is paramount for planning any functionality switch in the future.
Incubation
We propose creating a project under the llvm incubator umbrella at https://github.com/llvm/clangir to host our work. We plan on having this be a full llvm-project mirror with the ClangIR specific directories added within clang/lib , clang/include etc. as necessary.
Upstream direction
The criteria and requirements for inclusion upstream needs some clarification. We understand those will likely change over time but it’s important we get initial guidance. We grasped that design reviews and LLVM IR codegen are chief, but given the sky is the limit, it would be great to agree on some likely concrete goals.
Design reviews
Based on the feedback, we’d also like to propose starter topics for design reviews:
- Using AST nodes and types within CIR — from both a MLIR based implementation point of view and also its merits for simplifying different phases of codegen.
- Initial CIRToLLVM – is a minimal two-phase approach sufficient?
- Hybrid structured / unstructured control-flow. Progressive lowering without premature lowering.
- Criteria and requirements for future inclusion upstream
Our suggestion:
- An initial meeting to gather the interested folks in the subject, starting with a round table of introductions, go over each topic above and check if there are remaining points to be make to each of them. How about the week of July 18-22? I volunteer to coordinate and use @wsmoses suggestion (thanks again!):
- As we progress with our implementation and work on any of the related topics, we will post a design doc somewhere and create a new discourse thread, suggesting to gather and discuss. Perhaps a monthly MLIR C/C++ Frontend Working Group meeting should get rolling and we can just use that.