This is an archive of the discontinued LLVM Phabricator instance.

[mlir][python] Provide "all passes" registration module in Python
ClosedPublic

Authored by aartbik on May 25 2021, 5:43 PM.

Details

Summary

Currently, passes are registered on a per-dialect basis, which
provides the smallest footprint obviously. But for prototyping
and experimentation, a convenience "all passes" module is provided,
which registers all known MLIR passes in one run.

Usage in Python:

import mlir.all_passes_registration

Diff Detail

Event Timeline

aartbik created this revision.May 25 2021, 5:43 PM
aartbik requested review of this revision.May 25 2021, 5:43 PM

Can we have "register" somewhere in the name? This submodule won't do anything else right?
I would even consider making it a method instead:

import mlir
mlir.registerAllPasses()

Can we have "register" somewhere in the name?

I am following the other registration mechanism to the letter here, not one of them uses that technique or have "register" in the name.
I don't strongly feel either way, but what I did seemed much more consistent with the style used throughout.

PYBIND11_MODULE(_mlirLinalgPasses, m) {
  m.doc() = "MLIR Linalg Dialect Passes";
  // Register all Linalg passes on load.
  mlirRegisterLinalgPasses();
}
....
PYBIND11_MODULE(_mlirAsyncPasses, m) {
  m.doc() = "MLIR Async Dialect Passes";
  // Register all Async passes on load.
  mlirRegisterAsyncPasses();
}
....
etc.

The others may expose other content than just registration, in particular if/when we develop programmatic API for individual passes. This import is a) top-level which makes it more prominent and b) does not seem like it'll have any other purpose than registration.

The others may expose other content than just registration.

The other pass oriented imports don't expose anything but passes either.
For example we have

    import mlir.dialects.linalg.passes -> _load_extension("_mlirLinalgPasses") -> mlirRegisterLinalgPasses(); 
    import mlir.dialects.async         -> _load_extension("_mlirAsyncPasses")  -> mlirRegisterAsyncPasses();
    import mlir.dialects.gpu           -> _load_extension("_mlirGPUPasses")    -> mlirRegisterGPUPasses();
    import mlir.transforms             -> _load_extension("_mlirTransforms")   -> mlirRegisterTransformsPasses();
    import mlir.conversion             -> _load_extension("_mlirConversions")  -> mlirRegisterConversionPasses()

and I simply added

  import mlir.all_passes     ->  _load_extension("_mlirAllPasses") -> mlirRegisterAllPasses();

to this repertoire.This way a developer can simply start with "import mlir.all_passes", but then replace that line with a more restricted import when it turns out not everything is needed.

The others may expose other content than just registration.

The other pass oriented imports don't expose anything but passes either.

"don't expose anything" yet. That's the main difference: the others are design so that they can expose pass classes for example. This one won't.

Would:

import mlir.all_passes_registration

be acceptable to you (I believe using a noun is preferred over a verb here)?

I'd prefer a method call instead of a package, but I can live with that.

aartbik updated this revision to Diff 348058.May 26 2021, 12:49 PM

add "registration" to the import name

I'd prefer a method call instead of a package, but I can live with that.

Thanks Mehdi. PTAL

aartbik edited the summary of this revision. (Show Details)May 26 2021, 12:50 PM
mehdi_amini requested changes to this revision.May 26 2021, 1:11 PM
This revision now requires changes to proceed.May 26 2021, 1:11 PM

I hope you simply clicked the wrong button, but otherwise what changes would you like to see, my favorite sparring partner? ;-)

mehdi_amini accepted this revision.May 26 2021, 3:09 PM

Indeed :)

This revision is now accepted and ready to land.May 26 2021, 3:09 PM

(build was broken for a few days)

(build was broken for a few days)

Oops. Just saw this. I did not get any notification on that (but after chat I realize failure was masked by other failures)