aengelke wrote: > Adding a frontend-specific mechanism doesn't seem like the best approach to > me.
If we consider LLVM as a library that generates code and an alternative back-end as a different library that generates code, then it's up to the front-end to decide which library to use. No alternative back-end will be a fully compatible and transparent drop-in replacement for LLVM. The front-end should be in full control of which back-end it uses and any "LLVM plugin" (which is not a thing right now) should merely be able to change defaults. For example, a JIT compiler we would want to enable/disable an alternative back-end in ORC JIT through a runtime switch for every compilation (e.g., baseline vs. later optimized code generation). (Well ok, that's not quite accurate in the TPDE-LLVM case -- here, users will likely want to avoid ORC JITLink entirely and use TPDE's faster JIT mapper instead.) > move the hook into CodeGenTargetMachineImpl and manage to accommodate the > fallback case without breaking the interface. It would almost certainly need a new API if fallback is to be supported (which, for TPDE-LLVM, would be a fairly important requirement). While I think that our current addPassesToEmitX + PM.run API is not good, it's there and used.. a new API would need to be picked up by front-ends and it's not very likely that we'd deprecate the existing API? https://github.com/llvm/llvm-project/pull/165257 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
