[llvm-branch-commits] [RFC][Clang] Allow plugins to hook into back-end (PR #165257)

[Alexis Engelke via llvm-branch-commits]

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