[MLIR] Update Maintainers.md: add Python bindings under "Core"

[joker-eph]

See https://discourse.llvm.org/t/mlir-project-maintainers/87189

[llvmbot]

@llvm/pr-subscribers-mlir

Author: Mehdi Amini (joker-eph)

Changes

See https://discourse.llvm.org/t/mlir-project-maintainers/87189

---

Full diff: https://github.com/llvm/llvm-project/pull/153410.diff

1 Files Affected:

• (modified) mlir/Maintainers.md (+11)

diff --git a/mlir/Maintainers.md b/mlir/Maintainers.md
index c31b5c635fba3..77d415976f17c 100644
--- a/mlir/Maintainers.md
+++ b/mlir/Maintainers.md
@@ -27,6 +27,17 @@ dialects, build system and language bindings.
   [@joker-eph](https://github.com/joker-eph) (GitHub),
   mehdi_amini (Discourse)
 
+### Python Bindings
+
+ - Maksim Levental \
+   maksim.levental@gmail.com (email),
+   [@makslevental](https://github.com/makslevental) (GitHub),
+   makslevental (Discourse)
+ - Rolf Morel \
+   rolf.morel@intel.com (email)
+   [@rolfmorel](https://github.com/rolfmorel) (GitHub),
+   rolfmorel (Discourse)
+
 ## Egress
 
 MLIR components pertaining to egress flows from MLIR, in particular to LLVM IR.

[makslevental]

Although the original RFC states that the bindings are under Standalone subcategories within Core, I don't think it applies (as opposed to the other two topics). The bindings are completely decoupled from "core" and indeed that's supposedly intentional (i.e., widely expressed as the reasoning for using C APIs instead of C++ APIs). They also have no "load bearing" uses in-tree.

Can you tell me in which way you see these as "core" to upstream?

[joker-eph]

I see the same distinction as C++, what is "non-core" in MLIR are specific dialects (TOSA, linalg, etc.) or components well isolated for a specific use-case (like a GPU runtime or something similar).
On the other hand, what is "MLIR Core" is MLIR infrastructure that is generically applicable.
Things like builtin, SCF, UB, etc. aren't totally clear cut, but I see them as "core dialects".

In the bindings, I would differentiate the infra (which is "core") from the specific of each dialects. For example:

• Core Binding change: [mlir][python] automatic location inference #151246
• Not Core Binding change: [mlir][python] add scf.parallel/scf.forall helpers #150243

[makslevental]

I see the same distinction as C++, what is "non-core" in MLIR are specific dialects (TOSA, linalg, etc.) or components well isolated for a specific use-case (like a GPU runtime or something similar).
On the other hand, what is "MLIR Core" is MLIR infrastructure that is generically applicable.

This ontology is intra-component not inter-component i.e., it distinguishes between "core" subcomponents of any component (core and non-core dialects) but does not as far as I can see inductively translate into a single component being "core". If we take your definition then, for example, most of the utils suddenly become "core" since they're generically applicable.

So I believe the appropriate term here is generic rather than core (and indeed you've used it). I agree the bindings are generic but I'm still not convinced they're core to MLIR. To wit: you could remove them and absolutely nothing would fail in-tree except their own tests (and @grypp's integration tests) - this aligns with your bucketing too (if the GPU runtimes were removed, nothing would fail either other then their own tests and integration tests).

[joker-eph]

If we take your definition then, for example, most of the utils suddenly become "core" since they're generically applicable.

They are.

To wit: you could remove them and absolutely nothing would fail in-tree except their own tests

Seems like a tautology: I can remove almost anything in tree and the only things that will fail are the things that depend on the feature...
Because of the modular aspect of MLIR, if you go this route nothing is "core" other that the MLIRContext (and libMLIRIR I guess)?
E.g. I can remove DialectConversion and nothing will fail other than dialect conversion tests. Similarly for PDL/PDLL, or DRR...

[rengolin]

I'm not sure what this PR accomplishes. The currently open PR to add core sub-categories (#152136) already adds Python Bindings to Core. Why adding another competing PR?

[joker-eph]

I'm not sure what this PR accomplishes. Why adding another competing PR?

Occam razor: I wasn't aware of your PR... The way you're questioning it comes across a bit weird to me.

[makslevental]

I can remove DialectConversion and nothing will fail other than dialect conversion tests. Similarly for PDL/PDLL, or DRR...

That's certainly not true; if you remove DialectConversion then the unit tests for DialectConversion will and all the actual dialect conversions will fail; if you remove PDL/PDLL then transform dialect uses will fail; if you remove DRR then all those uses will fail.

[rengolin]

I'm not sure what this PR accomplishes. Why adding another competing PR?

Occam razor: I wasn't aware of your PR... The way you're questioning it comes across a bit weird to me.

You approved that PR...

[joker-eph]

That's certainly not true; if you remove DialectConversion then the unit tests for DialectConversion will and all the actual dialect conversions will fail;

What are "actual dialect conversions"?

[makslevental]

What are "actual dialect conversions"?

https://github.com/search?q=repo%3Allvm%2Fllvm-project+DialectConversion+path%3Amlir%2Flib+-path%3Amlir%2Flib%2FTransforms%2FUtils%2FDialectConversion.cpp+-path%3Amlir%2Flib%2FTransforms%2FUtils%2FCMakeLists.txt&type=code

[joker-eph]

I'm not sure we'll get anywhere: you're saying the python bindings are different because the project being written in C++ then the other non-core component in tree can't use it directly to implement transformations?
I don't quite see how this argument pertains to whether something is "core" to the MLIR infra/project or not really.

[rengolin]

As @makslevental mentioned, the ontology is flawed. We should not read too much into what "core" / "egress" / "tensor" means, as they were the initial step, not the end result.

For lack of a better place, we put python bindings under "core" because it's not egress/tensor related, but we can very well create another "unrelated" or "standalone" categories (possibly without "top" maintainers), so that we can bundle the loose parts of MLIR.

But it doesn't matter at this point, it's all nomenclature. We shall converge to a better state at some point, but for now, I'd like to get the original PRs merged and the initial list in tree. After that, we can start creating RFCs and PRs to change the current state.