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

Chandler Carruth via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 17 07:55:52 PDT 2019


chandlerc added a comment.

In D60814#1469963 <https://reviews.llvm.org/D60814#1469963>, @fedor.sergeev wrote:

> 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?


I see.

Yeah, the array-ref API here is already pretty leaky. It'd be really nice if we could only give the callbacks the necessary APIs here, but not sure its worth building that abstraction. I think the way I'd do it is create a parser type that is only built by the `PassBuilder` and is passed into the callbacks. It would then have these APIs, etc. It'd also be used internally to implement the main parsing API. Thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60814





More information about the llvm-commits mailing list