# MLIR Project Maintainers

**URL:** <https://discourse.llvm.org/t/mlir-project-maintainers/87189>\
**Category:** Announcements\
**Created:** [July 3, 2025, 5:03pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189 "2025-07-03T17:03:30Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![ftynse](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ftynse/32/18644_2.png) [@ftynse](https://discourse.llvm.org/u/ftynse)\
**Post date:** [July 3, 2025, 5:03pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/1 "2025-07-03T17:03:30Z")

</div>

The area team has carefully and extensively considered all (self-)nominations for maintainership, including late ones, and came up with the structure presented below. Given the complexity and breadth of the MLIR project, we propose a layered system with broad “categories” that are further subdivided per dialect or other component, rather than simple per-directory structure. This is purely an _information management_ decision that is not intended to have any effect on the project layout. The maintainers of categories are conferred with a maintenance burden of the entire category, including directories/dialects/components specifically covered by dedicated maintainers, similarly to how lead maintainers MLIR have the burden of maintaining the entire project in collaboration with other maintainers. Please [read more](https://llvm.org/docs/DeveloperPolicy.html#maintainers) about maintainer status in the LLVM Developer Policy. In particular, significant design changes require a forum RFC and a community-wide discussion, where the role of the maintainer is that of a mediator and a moderator, rather than that of a dictator.

Several dialects/components were considered “important enough” to be maintained directly by the category maintainers. These will have the name of the category listed instead of individual maintainer names. This name is _italicized_ below for readability.

Several other dialects/components do not have maintainers. We call them out below and _will consider removing them_ if nobody volunteers to maintain them. Until that moment, they are maintained by the relevant project and category maintainers.

We based our decisions on multiple criteria to ensure representation, fairness and compliance with the LLVM Developer Policy. In particular, we did not nominate as maintainers individuals who do not have a _recent track record_ of high-quality non-trivial contributions including PRs, reviews, bug reports, and public discussions. This is required by the Developer Policy. We also attempted, to the extent possible, to nominate multiple maintainers for every entry (being able to go on vacation is nice!). Finally, we tried to balance representation from different organizations whenever applicable, i.e., except vendor-specific components.

This list of maintainers is iterative and this is our first attempt at establishing one after more than 5 years of MLIR in the monorepo. It may and will evolve according to the policy in effect, and individual contributors are welcome to nominate themselves or somebody else according to the policy.

The list below uses Github handles (or my mistaken spelling of those).

Next steps:

- We will send a first PR committing the list of lead maintainers for approval by the Project Council members.
- After that, we will send PRs per category. These must be approved by the _nominees_ to record their agreement to take up the responsibility.
- After that, category maintainers are invited to follow the same process for individual entries within their category.  
Steps 2 and 3 are a direct transposition of the Developer Policy.

* * *

## Lead MLIR Project Maintainers (escalation / everything not covered below)

- ftynse
- jpienaar
- rengolin
- matthias-springer

## Core Category (core dialects / code base)

- jpienaar
- mehdi\_amini
- ftynse

### Standalone subcategories within Core

- CMake (christopherbate)
- Dialect Conversion (matthias-springer, zero9178)
- Python Bindings (makslevental, rolfmorel)

### Core Dialects

#### Code Structure Dialects

- [Builtin Dialect](https://mlir.llvm.org/docs/Dialects/Builtin/) (_core_)
- [‘func’ Dialect](https://mlir.llvm.org/docs/Dialects/Func/) (_core_)
- [‘scf’ Dialect](https://mlir.llvm.org/docs/Dialects/SCFDialect/) (_core_)
- [‘cf’ Dialect](https://mlir.llvm.org/docs/Dialects/ControlFlowDialect/) (_core_)
- [‘index’ Dialect](https://mlir.llvm.org/docs/Dialects/IndexOps/) (_core_)
- [‘ptr’ Dialect](https://mlir.llvm.org/docs/Dialects/PtrOps/) (fabianmcg)

#### Basic Compute Dialects

- [‘arith’ Dialect](https://mlir.llvm.org/docs/Dialects/ArithOps/) (_core_)
- [‘math’ Dialect](https://mlir.llvm.org/docs/Dialects/MathOps/) (_core_)

#### Rewrite System Dialects

- [Transform Dialect](https://mlir.llvm.org/docs/Dialects/Transform/) (martin-luecke, ftynse, rolfmorel)
- [‘pdl\_interp’ Dialect](https://mlir.llvm.org/docs/Dialects/PDLInterpOps/) (jpienaar)
- [‘pdl’ Dialect](https://mlir.llvm.org/docs/Dialects/PDLOps/) (jpienaar)

#### Accessory Dialects

- [‘affine’ Dialect](https://mlir.llvm.org/docs/Dialects/Affine/) (ftynse)
- [‘dlti’ Dialect](https://mlir.llvm.org/docs/Dialects/DLTIDialect/) (rolfmorel)
- [‘irdl’ Dialect](https://mlir.llvm.org/docs/Dialects/IRDL/) (math-fehr, moxinilian)
- [‘shape’ Dialect](https://mlir.llvm.org/docs/Dialects/ShapeDialect/) (jpienaar)
- [‘smt’ Dialect](https://mlir.llvm.org/docs/Dialects/SMT/) (fabianschuiki, maerhart)
- [‘complex’ Dialect](https://mlir.llvm.org/docs/Dialects/ComplexOps/) ( **unmaintained** )
- [‘ub’ Dialect](https://mlir.llvm.org/docs/Dialects/UBOps/) ( **unmaintained** )
- [‘async’ Dialect](https://mlir.llvm.org/docs/Dialects/AsyncDialect/) ( **unmaintained** )

## Egress Category (low-level dialects / code base)

- matthias-springer
- banach-space
- gysit

### Standalone Egress Subcategories

- LLVM Import (gysit, bcardosolopes)
- LLVM export (gysit, fabianmcg, zero9178)

### Egress Dialects

#### Lowering Dialects

- [‘llvm’ Dialect](https://mlir.llvm.org/docs/Dialects/LLVM/) (_egress_)
- [SPIR-V Dialect](https://mlir.llvm.org/docs/Dialects/SPIR-V/) (kuhar, antiagainst)
- [‘emitc’ Dialect](https://mlir.llvm.org/docs/Dialects/EmitC/) (gilrappaport, marbre)

#### GPU Dialects

- [‘gpu’ Dialect](https://mlir.llvm.org/docs/Dialects/GPU/) (fabianmcg)
- [‘amdgpu’ Dialect](https://mlir.llvm.org/docs/Dialects/AMDGPU/) (krzysz00)
- [‘rocdl’ Dialect](https://mlir.llvm.org/docs/Dialects/ROCDLDialect/) (krzysz00)
- [‘nvgpu’ Dialect](https://mlir.llvm.org/docs/Dialects/NVGPU/) (grypp)
- [‘nvvm’ Dialect](https://mlir.llvm.org/docs/Dialects/NVVMDialect/) (grypp)
- [‘xegpu’ Dialect](https://mlir.llvm.org/docs/Dialects/XeGPU/) (chencha3, Jianhui-Li)

#### CPU Dialects

- [‘arm\_neon’ Dialect](https://mlir.llvm.org/docs/Dialects/ArmNeon/) (banach-space)
- [‘arm\_sve’ Dialect](https://mlir.llvm.org/docs/Dialects/ArmSVE/) (banach-space)
- [‘ArmSME’ Dialect](https://mlir.llvm.org/docs/Dialects/ArmSME/) (banach-space)
- [‘amx’ Dialect](https://mlir.llvm.org/docs/Dialects/AMX/) (asiem)
- [‘x86vector’ Dialect](https://mlir.llvm.org/docs/Dialects/X86Vector/) (asiem)
- [‘vcix’ Dialect](https://mlir.llvm.org/docs/Dialects/VCIXDialect/) (mshockwave)

#### Paradigm Dialects

- [‘omp’ Dialect](https://mlir.llvm.org/docs/Dialects/OpenMPDialect/) (tblah, skatrak)
- [‘acc’ Dialect](https://mlir.llvm.org/docs/Dialects/OpenACCDialect/) (clementval, razvanlupusoru)
- [‘mpi’ Dialect](https://mlir.llvm.org/docs/Dialects/MPI/) (fschlimb)
- [‘mesh’ Dialect](https://mlir.llvm.org/docs/Dialects/Mesh/) (fschlimb)

## Tensor Category (tensor dialects / code base)

- rengolin
- banach-space
- jpienaar

### Tensor Dialects

#### Linear Algebra Dialects

- [‘linalg’ Dialect](https://mlir.llvm.org/docs/Dialects/Linalg/) (_tensor_)
- [Tensor Operator Set Architecture (TOSA) Dialect](https://mlir.llvm.org/docs/Dialects/TOSA/) (sjarus)

#### Type Dialects

- [‘tensor’ Dialect](https://mlir.llvm.org/docs/Dialects/TensorOps/) (_tensor_)
- [‘memref’ Dialect](https://mlir.llvm.org/docs/Dialects/MemRef/) (_tensor_)
- [‘vector’ Dialect](https://mlir.llvm.org/docs/Dialects/Vector/) (_tensor_ + dcaballe, groverkss)
- [‘sparse\_tensor’ Dialect](https://mlir.llvm.org/docs/Dialects/SparseTensorOps/) (aartbik, matthias-springer)

#### Accessory Dialects

- [‘bufferization’ Dialect](https://mlir.llvm.org/docs/Dialects/BufferizationOps/) (tensor, matthias-springer)
- [‘ml\_program’ Dialect](https://mlir.llvm.org/docs/Dialects/MLProgramOps/) (jpienaar)
- [‘quant’ Dialect](https://mlir.llvm.org/docs/Dialects/QuantDialect/) ( **unmaintained** )

---

<div class="post-metadata">

**Author:** ![kuhar](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/kuhar/32/573_2.png) [@kuhar](https://discourse.llvm.org/u/kuhar)\
**Post date:** [July 3, 2025, 6:16pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/2 "2025-07-03T18:16:19Z")

</div>

I was on a leave during the call for nominations and missed that thread or wherever that happened.

> [@ftynse](#):
>
> This list of maintainers is iterative

> Several other dialects/components do not have maintainers. We call them out below and _will consider removing them_ if nobody volunteers to maintain them.

If it’s not too late, you can also consider me for arith and ub. The latter is currently listed a unmaintained. @Hardcode84 is probably also interested.

---

<div class="post-metadata">

**Author:** ![ftynse](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ftynse/32/18644_2.png) [@ftynse](https://discourse.llvm.org/u/ftynse)\
**Post date:** [July 3, 2025, 6:35pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/3 "2025-07-03T18:35:17Z")

</div>

Thanks for volunteering! It may be too late for this particular process, but this is just the first slate to start. You are most welcome to just follow the regular procedure by sending a PR for approval to category maintainers once those are in place, I’ll let you know!

---

<div class="post-metadata">

**Author:** ![Hardcode84](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/hardcode84/32/793_2.png) [@Hardcode84](https://discourse.llvm.org/u/Hardcode84)\
**Post date:** [July 3, 2025, 6:36pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/4 "2025-07-03T18:36:35Z")

</div>

Yeah, I was the original author of the `ub` dialect, you can add me too I guess.

---

<div class="post-metadata">

**Author:** ![dcaballe](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/dcaballe/32/22025_2.png) [@dcaballe](https://discourse.llvm.org/u/dcaballe)\
**Post date:** [July 3, 2025, 9:43pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/6 "2025-07-03T21:43:21Z")

</div>

Thanks for all the effort the area team is putting into this!

Having maintainers for the `ub` dialect would be important, indeed. The `ub.poison` op has already been adopted in a few places of the ecosystem. Having dedicated maintainers that can help fill some of the existing implementation gaps (e.g., representational support for partially poison vector types) would be highly appreciated.

---

<div class="post-metadata">

**Author:** ![hhkit](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/hhkit/32/21087_2.png) [@hhkit](https://discourse.llvm.org/u/hhkit)\
**Post date:** [July 15, 2025, 2:44pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/7 "2025-07-15T14:44:54Z")

</div>

This is probably a little off-topic, but I found this taxonomy of the different dialects really helpful for demystifying what the different dialects in MLIR are and where one might want to focus their learning efforts if they were new. At the very least, it’s way more useful than [what we currently have](https://mlir.llvm.org/docs/Dialects/).

Should it be encoded in the documentation somewhere, somehow?

---

<div class="post-metadata">

**Author:** ![ftynse](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ftynse/32/18644_2.png) [@ftynse](https://discourse.llvm.org/u/ftynse)\
**Post date:** [July 15, 2025, 5:40pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/8 "2025-07-15T17:40:14Z")

</div>

We intentionally don’t propose a way to structure the project with this change, that should be a separate discussion, but this list may be a good starting point for that convresation.

---

<div class="post-metadata">

**Author:** ![rengolin](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/rengolin/32/327_2.png) [@rengolin](https://discourse.llvm.org/u/rengolin)\
**Post date:** [July 15, 2025, 6:05pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/9 "2025-07-15T18:05:51Z")

</div>

> [@hhkit](#):
>
> Should it be encoded in the documentation somewhere, somehow?

Definitely something we need to discuss soon (not here). The taxonomy came from the [survey](https://discourse.llvm.org/t/survey-mlir-project-charter-and-restructuring-survey/82996) and encodes the _“current usage”_ more than the _“expected classification”_. But since most dialects are used by more than they were designed for, an expected classification would also be somewhat “wrong”.

Since maintainers need to worry about code and usability, it’s more actionable to bundle by usage at least in a first attempt. But as was said above and elsewhere, this is the first list, not the final one (if there will ever be a final one).

We should continue to evolve and yes, document them more prominently, so that it’s easier and faster to learn about MLIR, which will hopefully increase contributors.

---

<div class="post-metadata">

**Author:** ![ftynse](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ftynse/32/18644_2.png) [@ftynse](https://discourse.llvm.org/u/ftynse)\
**Post date:** [July 18, 2025, 10:12am UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/10 "2025-07-18T10:12:31Z")

</div>

These nominations were discussed at the LLVM Project Council meeting on July 17. As the Project Council and the Area Team currently lack clarity on the exact scope of responsibilities for lead maintainers, we will be holding off those nominations until the Project Council clarifies those so nominations can be evaluated with more objective criteria.

In the meantime, as agreed during the same meeting, we are proceeding with nominations of category maintainers. As an exception, in absence of lead or any other maintainers for the project, the Area Team may approve the nominations as discussed during the same Project Council meeting.

**Action Items** :

- nominees: please confirm the nomination by approving the PR; your approval means accepting the burden of maintainership and nothing more;
- everyone: if you have any specific concerns regarding a nominee, please raise them on the PR in such a way that the nomination can be defended; in exceptional cases, you may contact the Area Team via Discourse; if you have concerns that fall under [Code of Conduct](https://llvm.org/docs/CodeOfConduct.html), please reach out to the Code of Conduct committee.

We will keep these PRs open for a couple of days, but given that there was no specific opposition to these nominations for the two weeks since the initial post, we expect to be able to merge the PRs some time next week. Note that these are PRs just like others and they can be reverted should a major concern arise after merging.

> <https://github.com/llvm/llvm-project/pull/149485>
>
> This is a nomination for the maintainers of the core category within MLIR as pro…posed in https://discourse.llvm.org/t/mlir-project-maintainers/87189. As agreed in the Project Council meeting on July 17, we are proceeding with category nominations without waiting for lead maintainers to be nominated.

> <https://github.com/llvm/llvm-project/pull/149487>
>
> This is a nomination for the maintainers of the egress category within MLIR as p…roposed in
> https://discourse.llvm.org/t/mlir-project-maintainers/87189. As agreed in the Project Council meeting on July 17, we are proceeding with category nominations without waiting for lead maintainers to be nominated.

> <https://github.com/llvm/llvm-project/pull/149488>
>
> This is a nomination for the maintainers of the tensor compiler category within …MLIR as proposed in
> https://discourse.llvm.org/t/mlir-project-maintainers/87189. As agreed in the Project Council meeting on July 17, we are proceeding with category nominations without waiting for lead maintainers to be nominated.

Alex on behalf of the Area Team and Project Council

---

<div class="post-metadata">

**Author:** ![ftynse](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ftynse/32/18644_2.png) [@ftynse](https://discourse.llvm.org/u/ftynse)\
**Post date:** [July 21, 2025, 7:15am UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/12 "2025-07-21T07:15:27Z")

</div>

Linalg is intentionally deferred to tensor category maintainers.

> [@ftynse](#):
>
> Several dialects/components were considered “important enough” to be maintained directly by the category maintainers.

---

<div class="post-metadata">

**Author:** ![javedabsar](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/javedabsar/32/1657_2.png) [@javedabsar](https://discourse.llvm.org/u/javedabsar)\
**Post date:** [July 21, 2025, 9:09am UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/13 "2025-07-21T09:09:44Z")

</div>

what about ‘quant’ and ‘async’ which shows as `unmaintained`. Is it intention to not maintain it or nobody came forward.

---

<div class="post-metadata">

**Author:** ![rengolin](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/rengolin/32/327_2.png) [@rengolin](https://discourse.llvm.org/u/rengolin)\
**Post date:** [July 21, 2025, 9:37am UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/14 "2025-07-21T09:37:07Z")

</div>

These will be done at a later stage. The PRs are not the end of the matter, just the beginning.

---

<div class="post-metadata">

**Author:** ![ftynse](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ftynse/32/18644_2.png) [@ftynse](https://discourse.llvm.org/u/ftynse)\
**Post date:** [July 28, 2025, 8:06am UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/15 "2025-07-28T08:06:43Z")

</div>

The category maintainers lists are being merged now. I would kindly ask category maintainers to populate the list further from the post above following the same process. Nominees listed above may also open PRs and ask category maintainers and other nominees to approve them.

I think, at this point, folks willing to volunteer for currently-unmaintained parts are welcome to send PRs nominating themselves for review by relevant category maintainers. Once we are done with the initial list from above, additional maintainers can be nominated everywhere if desired.

---

<div class="post-metadata">

**Author:** ![rengolin](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/rengolin/32/327_2.png) [@rengolin](https://discourse.llvm.org/u/rengolin)\
**Post date:** [July 28, 2025, 12:57pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/16 "2025-07-28T12:57:41Z")

</div>

Regarding the differences between dialect maintainers, here’s my view of the rationale behind:

- The ones marked with **_team_** are the core dialects and are a share responsibility of the whole team. These should never be moved out of MLIR, unless the whole community agrees to do so, with strong consensus.
- The ones with **_team_** and additional maintainers are still the responsibility of the team, but those people are most active in their design. Questions should be directed to these people before the core team. If they cease their activities, ownership goes back to the team.
- The ones with just named maintainers are alternative / side dialects that have an active community behind. If they cease their activities, the dialect becomes **_unmaintained_**.
- The ones marked **_unmaintained_** are those that the underlying community has ceased (or drastically reduced) support and will need new maintainers or be considered for removal.

Note that the maintainer list does not cover _everyone_ that works on the dialect, just those that are responsible for its maintenance. This is more of a janitor’s job than a head teacher, as there’s no additional power bestowed (as per the [LLVM policy](https://llvm.org/docs/DeveloperPolicy.html#maintainers)).

---

<div class="post-metadata">

**Author:** ![rengolin](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/rengolin/32/327_2.png) [@rengolin](https://discourse.llvm.org/u/rengolin)\
**Post date:** [July 28, 2025, 1:14pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/17 "2025-07-28T13:14:35Z")

</div>

> <https://github.com/llvm/llvm-project/pull/150945>
>
> As per https://discourse.llvm.org/t/mlir-project-maintainers/87189
> 
> @llvm/mlir…-area-team
> @jpienaar
> @banach-space

---

<div class="post-metadata">

**Author:** ![jpienaar](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/jpienaar/32/225_2.png) [@jpienaar](https://discourse.llvm.org/u/jpienaar)\
**Post date:** [July 30, 2025, 5:54am UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/18 "2025-07-30T05:54:58Z")

</div>

I’d mention that not everyone monitors Discourse as actively. Some more follow Github/code . So I suspect this changes as visibility increases (this is also the first roll out of this, so some may want to see it play out first). But then yes, responsibility for maintaining goes upwards through “gaps”. E.g., if dialect has no direct maintainer, then “group” its under is maintainer, if under no group or group not responsive, go up 🙂

---

<div class="post-metadata">

**Author:** ![rengolin](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/rengolin/32/327_2.png) [@rengolin](https://discourse.llvm.org/u/rengolin)\
**Post date:** [August 11, 2025, 10:58am UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/19 "2025-08-11T10:58:46Z")

</div>

For reference:

> <https://github.com/llvm/llvm-project/pull/151721>
>
> As per https://discourse.llvm.org/t/mlir-project-maintainers/87189, this PR adds… maintainers for the "egress" dialects. 
> 
> Compared to the original proposal, two changes are included:
> \* The "mesh" dialect has been renamed to "shard" (https://discourse.llvm.org/t/mlir-mesh-cleanup-mesh/).
> \* The "XeVM" dialect has been added (https://discourse.llvm.org/t/rfc-proposal-for-new-xevm-dialect/).

> <https://github.com/llvm/llvm-project/pull/152136>
>
> Ref: https://discourse.llvm.org/t/mlir-project-maintainers/87189
> 
> See also:
> …\* #151721 
> \* #150945
> 
> Compared to the original proposal, one change is included:
> \* The \`ub\` dialect has @Hardcode84 as maintainer.
> 
> Please accept to validate your nomination, let's keep new nominations for follow up PRs.

---

<div class="post-metadata">

**Author:** ![sjarus](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/sjarus/32/1237_2.png) [@sjarus](https://discourse.llvm.org/u/sjarus)\
**Post date:** [August 11, 2025, 3:35pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/20 "2025-08-11T15:35:24Z")

</div>

Regarding the quant dialect, I’d like to refer to a couple of recentish RFCs and solicit maintainer interest:

@rafaelubal : [[RFC] Improvements in the 'quant' dialect](https://discourse.llvm.org/t/rfc-improvements-in-the-quant-dialect/79942)

@sdasgup3 : [RFC: Supporting Sub-Channel Quantization in MLIR](https://discourse.llvm.org/t/rfc-supporting-sub-channel-quantization-in-mlir/82694)

---

<div class="post-metadata">

**Author:** ![mehdi\_amini](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/mehdi_amini/32/25595_2.png) [@mehdi\_amini](https://discourse.llvm.org/u/mehdi_amini)\
**Post date:** [August 13, 2025, 1:36pm UTC](https://discourse.llvm.org/t/mlir-project-maintainers/87189/21 "2025-08-13T13:36:02Z")

</div>

For Python bindings: [[MLIR] Update Maintainers.md: add Python bindings under "Core" by joker-eph · Pull Request #153410 · llvm/llvm-project · GitHub](https://github.com/llvm/llvm-project/pull/153410)