================ @@ -0,0 +1,236 @@ +================================ +ClangIR Code Duplication Roadmap +================================ + +.. contents:: + :local: + +Introduction +============ + +This document describes the general approach to code duplication in the ClangIR +code generation implementation. It acknowledges specific problems with the +current implementation, discusses strategies for mitigating the risk inherent in +the current approach, and describes a general long-term plan for addressing the +issue. + +Background +========== + +The ClangIR code generation is very closely modeled after Clang's LLVM IR code +generation, and we intend for the CIR produced to eventually be semantically +equivalent to the LLVM IR produced when not going through ClangIR. However, we +acknowledge that as the ClangIR implementation is under development, there will +be differences in semantics, both because we have not yet implemented all +features of the classic codegen and because the CIR dialect is still evolving +and does not yet have a way to represent all of the necessary semantics. + +We have chosen to model the ClangIR code generation directly after the classic +codegen, to the point of following identical code structure, using similar names +and often duplicating the logic because this seemed to be the most certain path +to producing equivalent results. Having such nearly identical code allows for +direct comparison between the CIR codegen and the LLVM IR codegen to find what +is missing or incorrect in the CIR implementation. + +However, we recognize that this is not a sustainable permanent solution. As +bugs are fixed and new features are added to the classic codegen, the process of +keeping the analogous CIR code up to date will be a purely manual process. + +Long term, we need a more sustainable approach. + +Current Strategy +================ + +Practical considerations require that we make steady progress towards a working +implementation of ClangIR. This necessity is directly opposed to the goal of +minimizing code duplication. + +For this reason, we have decided to accept a large amount of code duplication +in the short term, even with the explicit understanding that this is producing +a significant amount of technical debt as the project progresses. + +As the CIR implementation is developed, we often note small pieces of code that +could be shared with the classic codegen if they were moved to a different part +of the source, such as a shared utility class in some directory available to +both codegen implementations or by moving the function into a related AST class. +It is left to the discretion of the developer and reviewers to decide whether +such refactoring should be done during the CIR development, or if it is +sufficient to leave a comment in the code indicating this as an opportunity for +future improvement. Because much of the current code is likely to change when +the long term code sharing strategy is complete, we will lean towards only +implementing refactorings that make sense independent of the code sharing +problem. + +We have discussed various ways that major classes such as CGCXXABI/CIRGenCXXABI +could be refactored to allow parts of there implementation to be shared today +through inheritence and templated base classes. However, this may prove to be +wasted effort when the permanent solution is developed, so we have decided that +it is better to accept significant amounts of code duplication now, and defer +this type of refactoring until it is clear what the permanent solution will be. ---------------- AaronBallman wrote:
It may be worth noting that duplicating the code also makes removal of CIR less risky should CIR fail to pan out long-term. I know this isn't an expected (or desired) outcome, but the less interdependence we have between CIR and current IR gen, the easier it is to make those kinds of significant decisions. https://github.com/llvm/llvm-project/pull/166457 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
