andykaylor wrote: > Another way of putting that is that you are cloning IRGen on autopilot and > making a lot of extra work for yourselves in the process. You should be > thinking carefully about what operations should stay abstract in ClangIR as > you go along rather than "following the known code patterns" and then > realizing months later that that wasn't a good use of time. > > I do not see any good reason that `typeid` needs to be lowered in ClangIR. > There should be an abstract operation to emit a reference to the > `std::type_info` for a concrete type, and another abstract operation to emit > a reference to the dynamic `std::type_info` of a specific object. They can > stay like that in ClangIR, and then the final lowering step to LLVM will then > call into the existing routines for emitting RTTI objects in the appropriate, > target-specific way.
You're right that transformations working with CIR shouldn't need this level of detail. However, at the moment we're focused on trying to make compilation through CIR a fully functional path that can compile real programs. What that means is that we want to have the complete AST->CIR->LLVM dialect->LLVM IR->binary path as we add things. So even though we could (and arguably should) use some kind of abstraction at the top level of CIR generation, we need the detail pieces immediately as we lower this to the LLVM dialect. At that point, having something that shares the structure of the existing LLVM IR CodeGen is the path of least resistance. As I mentioned before, we've been deferring most of the work to actually try to share that code, and maybe we should again in this case for the parts that require IR-specific constructs, but "cloning IRGen on autopilot" is generally the quickest way to get something working, particularly in light of the fact that it's already been implemented that way in the incubator. (That is, we're actually cloning the incubator not-quite-on-autopilot after the incubator had already cloned IRGen not-quite-on-autopilot, hopefully improving things on each iteration. We're trying to question things as we go so everyone is happy with the code that lands upstream, which is what led to the discussion here.) https://github.com/llvm/llvm-project/pull/157936 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
