This commit refactors the current pass manager support to allow for
operation agnostic pass managers. This allows for a series of passes
to be executed on any viable pass manager root operation, instead
of one specific operation type. Op-agnostic/generic pass managers
only allow for adding op-agnostic passes.
These types of pass managers are extremely useful when constructing
pass pipelines that can apply to many different types of operations,
e.g., the default inliner simplification pipeline. With the advent of
interface/trait passes, this support can be used to define FunctionOpInterface
pass managers, or other pass managers that effectively operate on
specific interfaces/traits/etc (see #52916 for an example).
I had to read through the docs a couple of times to get my head around the definitions. Perhaps an explicit tie-in that op-agnostic passes can be filtered (and then refer to below). Maybe change the parenthetical:
..., or op-agnostic (not restricted to a static operation type, but optionally filtered -- see below)
Basically, I think it bears more explicit calling out that filtered passes are a type of op-agnostic passes.
I also think that a person not coming in with the historic context would ask why we distinguish these two types of passes/pass-managers (i.e. aren't op-specific passes/pass-managers just a type of op-agnostic but filtered to a specific operation type). I suspect that there is a reason (perf?) for special casing this, but might be useful to call this out.