This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Pass] Add support for an InterfacePass and pass filtering based on OperationName
ClosedPublic

Authored by rriddle on Mar 1 2022, 9:58 PM.

Details

Summary

This commit adds a new hook Pass bool canScheduleOn(RegisteredOperationName) that
indicates if the given pass can be scheduled on operations of the given type. This makes it
easier to define constraints on generic passes without a) adding conditional checks to
the beginning of the runOnOperation, or b) defining a new pass type that forwards
from runOnOperation (after checking the invariants) to a new hook. This new hook is
used to implement an InterfacePass pass class, that represents a generic pass that
runs on operations of the given interface type.

The PassManager will also verify that passes added to a pass manager can actually be
scheduled on that pass manager, meaning that we will properly error when an Interface
is scheduled on an operation that doesn't actually implement that interface.

Diff Detail

Event Timeline

rriddle created this revision.Mar 1 2022, 9:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2022, 9:58 PM
rriddle requested review of this revision.Mar 1 2022, 9:58 PM
rriddle added inline comments.
mlir/lib/Pass/Pass.cpp
223

@mehdi_amini I went back and forth on what behavior we want here, would love to hear what you think. The patch as-is drops passes that can't be executed (with a log), but we could also emit a fatal error/diagnostic/something here instead. We can't emit an error at the time of insertion because we don't have the OperationName at that point (the dialect might not be loaded).

rriddle updated this revision to Diff 412583.Mar 2 2022, 5:55 PM
rriddle edited the summary of this revision. (Show Details)
mehdi_amini added inline comments.Mar 3 2022, 3:13 AM
mlir/include/mlir/Pass/Pass.h
409

The doc seems copy/pasted but you forgot to update it?

mlir/lib/Pass/Pass.cpp
223

I'm concerned about a fatal_error here in the sense that this can trip on a user input. We should have a way for a client to validate a parsed pipeline with a proper error recovery.

Think about this kind of thing: https://github.com/llvm/llvm-project/blob/main/mlir/test/python/pass_manager.py#L39-L44 ; where we shouldn't just crash the process.

Can we diagnose an error and make finalizePassList returns a LogicalResult to propagate upward?

rriddle updated this revision to Diff 412748.Mar 3 2022, 9:40 AM
rriddle marked 2 inline comments as done.
mehdi_amini accepted this revision.Mar 4 2022, 12:15 PM
This revision is now accepted and ready to land.Mar 4 2022, 12:15 PM
This revision was landed with ongoing or failed builds.Mar 4 2022, 3:14 PM
This revision was automatically updated to reflect the committed changes.