High level summary We propose beginning in-tree development of an experimental ml_program dialect which can help provide some standard containers and structural ops to unify the outer level of ML computations. This is a completely reworked v2 proposal based on the discussions that came out of RFC: I…

[image] stellaraccident: I think there is a bit more to it than that, and actual existing systems that I am aware of do the latter (i.e. Glow or even TF if you stare closely enough) and treat the “compiler” as more of a traditional compiler+linker or LTO thing for cases where the contents are re…

[image] stellaraccident: OMG, now that you say that, I can’t unsee it ( public static void main ). You are totally right. The intent was to be close to LLVM in function – aligning the syntax as you propose sgtm (just verifying – I think your critique is just syntax, right?). It would’ve been …

Ok, I’m going to prepare patches today for: ml_program.global op and an ml_program.global_load_const op which makes it minimally useful (deferring the side effecting load/store ops to a followup, since that is where discussion remains) A library and tool defining the external data files I expect…

@stellaraccident - do you already have passes for ml_program.func and func.func interconversion?

No - if you need those now, I won’t get to it in the next few days and would welcome a patch.

Hi folks, here is the next patch in the series: ⚙ D126230 [mlir] Add global_load and global_store ops to ml_program. Note that we did not converge on the design of this in the original thread: there were different opinions with respect to graph vs imperative handling. I am proposing this by way of …

My understanding was that the safer way was to make sure was always have equal support for graph and imperative region?

I recall that being one of the viewpoints, but I heard at least as strong support for the alternative: load/store ops that accept/produce an access token are different ops and we don’t need them to be unified. Within this alternative, there was also a side discussion that could potentially blend the…

[image] stellaraccident: load/store ops that accept/produce an access token are different ops and we don’t need them to be unified. I don’t get this: how are they different? (Other than having a token?) As far as I understand a version of this op that returns a token and accepts an optional …

RFC: Introduce ml_program dialect and top-level ops (proposal v2)

MLIR

_sean_silva April 26, 2022, 8:40am 51

We will get to it eventually as part of our ml_program integration effort, so if it’s not blocking you no need to do it.

Topic		Replies	Views
RFC: Introduce ml_program dialect (deprecated v1 proposal) MLIR	33	2842	March 12, 2022
[RFC] Allowing Dialects to relax the SSA-dominance condition MLIR	94	6103	July 18, 2020
Development of high-level Tensor Compute Primitives dialect(s) and transformations Tensor Compiler	79	12991	September 8, 2021
Open MLIR Meeting 2/17/2022: IREE’s input dialect Announcements	10	1230	February 20, 2022
RFC: MPS dialect in MLIR MLIR	36	3058	July 21, 2025

RFC: Introduce ml_program dialect and top-level ops (proposal v2)

Related topics