MLIR generic IR stability and upgradability

Hi,

I might be missing a lot of context or info,

As was put nicely above.

I would like to ask is there a discussion going on about stability? Or atleast a place where there is a clear upgradability path defined or required for any future bytecode format breaking changes?

To me there are different pieces:

  1. The generic IR representation structure
  2. The bytecode format
  3. LLVM monorepo core Dialects (Function, builtin, etc)
  4. Other LLVM monorepo dialects (LLVM, SpirV, etc.)

And here I am requesting 1 and 2 for our dialect on which we can guarantee stability or upgradability, any plans or ETAs for it so we can plan around it?

It would be nice to use the MLIR serialization format and bytecode confidently instead of worrying about it breaking someday with no path to upgrade.

I think that now that the mechanism is becoming available, we will need to make dialect by dialect decisions about policy. While some manner of compatibility is a good thing, imo, it isn’t a decision to be taken lightly or all at once – many of these things weren’t designed to just have stability enforced on a whim, so we need to figure out how to discuss this and decide.

As an example, in OpenXLA, we are deciding to decouple the stable dialect (“StableHLO”) from the lower level dialects and only have guarantees there. We are further discussing phasing in more guarantees, first with short windows and then further as work is done to make sure it is as long term viable path. These things can be really valuable, but it takes real work and investment. I don’t know that we’ve started this discussion for any of the in-tree dialects. We should but we also need to be conservative in expectations given the investments involved.

Hi @stellaraccident

Totally agreed it will be incremental progress, for now my need is only that if I am serializing my own dialect IR using the bytecode today then there is some sort of guarantee the upstream changes won’t break it or atleast if they do then there is a way to upgrade that bytecode to the new stuff.

Having func and builtin dialect be stable (because we use func, module and return ops) will be an added plus but not a blocker per say.

That I am hoping might be a much smaller piece to handle and guarantee and maybe is the first step anyways.

This is the goal, we just haven’t yet reached the point where we claim stability.
We’ve been actively discussing some aspects of it though: it isn’t straightforward… What does “stability” means in the first place? “compatibility”: backward vs forward? Between which version of the code (we don’t have releases right now!).