[PATCH] D60814: [PassBuilder] promote pass-pipeline parsing API to public

[Fedor Sergeev via Phabricator via llvm-commits]

fedor.sergeev added a comment.

In D60814#1469844 <https://reviews.llvm.org/D60814#1469844>, @philip.pfaffe wrote:

> What is your specific usecase for this? You have a custom PassManager which can contain, e.g., a function pass pipeline?


Right. We are building our own "kinda-SCC" pass manager, which runs inlining-devirtualization iteration doing walk over functions in rather different order than current SCC does.
This pass manager right now accepts at least one function pass pipeline (and we think about adding one more), and I would like to be able to populate this pass manager from -passes.

So, I'm using a module-pipeline parsing callback:

  bool parseOurPipeline(StringRef Name, ModulePassManager &PM,
                        ArrayRef<PassBuilder::PipelineElement> InnerPipeline,
                        PassBuilder &PB) {
     if (Name == "our-pass-manager") {
        FunctionPassManager SimplifyPM;
        if (auto Err = PB.parseFunctionPassPipeline(SimplifyPM, InnerPipeline, false, false))
         return false;
       PM.addPass(OurPassManager(std::move(SimplifyPM)));
       return true;
    }
  }

and then

  PB.registerPipelineParsingCallback(
        [&PB](StringRef Name, ModulePassManager &PM,
            ArrayRef<PassBuilder::PipelineElement> InnerPipeline) {
        return parseOurPipeline(Name, PM, InnerPipeline, PB);
       });

So thats basically a problem of introducing a custom pass manager that can be fully handled by -passes=.

I agree that it looks like exposing implementation detail.
But then, isnt passing ArrayRef<PipelineElement> to pipeline-parsing callback already exposing this implementation detail?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60814/new/

https://reviews.llvm.org/D60814