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

[stellaraccident]

Some other responses from questions posed up-thread:

@mehdi_amini

The naming: I’m not sure about having “ML” in the name. As long as you don’t have first class support for things like gradients and optimizers, what is specific to ML? Is there a more descriptive name for what the dialect entails?

Speaking personally, I dislike the “ML-ification” of basic things like math, and I’ve generally tried to avoid using the “ML” prefix (at least to mean literally “machine learning” versus some other tongue in cheek thing) as a result. However, I think there is actually a real gap here with respect to the commonalities that exist in multiple ML frameworks in the wild, each of which has years of mileage and, collectively, billions of users on them. I think by naming it anything other than “ML” at this point, we are not acknowledging this reality. It hurts me a bit to make this argument, but I think it is true.

Plus, in the future, once this fad moves on, we can all convince ourselves that it just means “multi-level programs”

@bondhugula

I feel if we don’t look at this generally and in conjunction with the existing upstream dialects, we risk adding too many duplicate ops and parallel paths – it’s possible some of the things you wish to support either fit well into an existing dialect or another new dialect or supported by existing ops with extensions if needed.

Possibly they do. With this RFC, we seem solidly on the incremental path of discussing ops at a time. I think this will afford us plenty of visibility to perform such an initial sort. The counter-argument is that if we have multiple frameworks in a domain defining the same high-level concept, there is some benefit to collecting those things in a way that preserves their heritage. This tends to be quite different from how one sorts “low level” concepts, in my experience.

@jfurtek

@bondhugula

Lists, initializers, and globals appear to be of general use and aren’t something specific to ml. Do you want to call this the program dialect?

As for naming the dialect ml_program , I’m old enough to remember when “ML” in MLIR stood for “multi-level”, and not “machine learning.”

We can debate that for those ops when they come up. As a counter-argument, for things aligned with some common, domain specific thing, it can be useful to have an isomorphic representation for that domain that holds together. Such things that are more frontend aligned, ime, often have subtleties in their modeling that would be different if attempting to do canonically at the lowest levels.

@jfurtek

Would a top-down design approach be possible? Instead of creating and populating an ml_program dialect just to get the ball rolling, try to map out an initial dialect map? This would have advantages from a division of labor perspective (if you are looking for help implementing), and might allow for more graceful design iteration than the alternative of moving things out of ml_program after frameworks have already started using them.

Speaking personally, I’ve been in multiple of these kinds of situations and such an exercise never converged if not approached in an informed but incremental fashion. This space is vast, and while a few of us have significant slices of it in our heads, no one has a complete picture (to say nothing of an unbiased picture). Largely being in the category of “dealing with the past”, I think the only way to do it is incrementally, topic by topic, from the bottom.

@jfurtek

It seems like defining norms and leaving design comments can be done even if things are distributed among multiple dialects.

One advantage to the ml_program dialect approach being propseed is that it avoids extended discussions on “what should this dialect be called?” or “what should be in this dialect?” Does that outweigh the effort that would be required to extract things from ml_program into a different dialect down the road? I will defer to your expertise - just wanted to re-raise these issues one more time.

To be clear, I think that we will ultimately end up with multiple dialects that compose together. But it is important to start with something simple and then have the diligence to look at it and split/rearrange over time before it solidifies too much.