weliveindetail wrote: > The front-end should be in full control of which back-end it uses
Yes, as a pure backend selection feature in the frontend, this is fair. It doesn't fit my use-case where a pass plugin requires a different/modified codegen backend, but that might just be a different story. I think we should wait for feedback from clang maintainers then. > 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? The switch to the new pass manager might actually be a good opportunity to revisit the interface. It follows the same approach to split populate and run, but it wouldn't need to be exposed that way. [llc implements it here](https://github.com/llvm/llvm-project/blob/4254f2777cd3dccf160c79e36ce091d58b4e99c1/llvm/tools/llc/NewPMDriver.cpp#L88) and calls into TargetMachine's new `buildCodeGenPipeline()` callback. 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
