PassInstrumentation would do much of this per pipeline, with the exception of errors reported and signalPassFailures not stopping the pass before its run, but would probably result in stopping pipeline post I believe (one could try).
What folks often do here is create explicit verification passes. This enables verification that is not restricted to the object granularity of the pass being run (e.g., the verfiyBefore and verifyAfter functions can’t verify something about the parent Module/symbols if the pass is a Func pass).
Something like this can be done with dynamic pipelines. And one could wrap it such that it looks something like
addPass(createExecuteIf<checkNoSCF>(createMyPass()));
Now that is just set in C++ (so generating docs would be hard unless we added a describe option to passes or could rely on some tool to extract, but can be customized per application pipeline rather than pass). This, conditional gating, is something not mentioned in the rest as verification can be turned on or of, and signals pass failure, while bypass I expect has to be on always.
The same approach could also be done for just verification of course. Either with a wrapping pass or one could also have builders like
addPass(precondition, pass, postcondition);
and it ends up adding multiple passes really, where the precondition and postcondition “pass” is (hand waving) a wrapper pass around a function that returns LogicalResult. Well it would end up doing so where verification is enabled – although one can today enable verifier post making pipeline, so may have to make verification sticky post addPass call or fail if adjusted with passes added.
It is still per pipeline and discoverable when one looks at pipeline, but MD generation again not free. And if documentation generation (beyond just writing it in the pass description, where Mehdi’s example’s comment feels more like something I’d want displayed and the actual code noisy TBH) is main concern, then also consideration for how we could combine ODS doc generation, doxygen & perhaps runtime querying to improve.
Yes, SCF is not the only thing going to CF nor does one always want everything to go to LLVM in a module, so it couldn’t be a precondition of the pass and the pass is happy without. Now, in the LLVM dialect translation to LLVM IR, one could flag remaining SCF ops and suggest the pass - as there it would fail and be a helpful user/compiler dev hint, but it wouldn’t help track down which pipeline to update. Even with that I consider that a win still. But one may want that pluggable (“explainers” as to why something went wrong that on could register kind of …)
I’m assuming here these are more for compiler developers than end users of the tools. Mostly as this isn’t actionable for tool users.