Towards MLIR Bytecode format stability and backward compatibility

MLIR
1

Hi all,

recently we have been working on dialect IR versioning (⚙ D143647 Extension of "Implement IR versioning through post-parsing upgrade through OpAsmDialectInterface") as we wish to ship a backward compatible serialization format. As part of the review we discussed with @mehdi_amini what the bytecode format still needs to reach a stability point. Among the topics mentioned:

  • Dialect Versioning;
  • Use-list order;
  • Lazy-loading ability.

It was also mentioned that the work @mehdi_amini is doing on properties should still allow backward compatibility when it lands.

Are there any other features of interest that should be supported by the bytecode format before reaching a stability point? Is there a timeline already for which backward compatibility is expected?

Our goal is to achieve this backward compatibility by May/June and ship bytecode based serialization format.

1 Like
2

It should be noted that we’re discussing only the compatibility of the bytecode, independently of dialects.
Claiming stability for the bytecode won’t make automatically upstream dialects stable.

3

It should be noted that we’re discussing only the compatibility of the bytecode, independently of dialects.

absolutely,

we are good with upstream dialects changing, as long as we add some version to the func dialect (which is the only one we use)

And if that doesn’t happen we can create our own func op and work around it in our serialization.

We just need to figure our how to make bytecode stable by May/June.

2 Likes
4

This is great. Having a v1 of bytecode that is stable for deployment by then sounds feasible.

Note: some parts here, e.g., lazy-loading, could even be done using the existing approach and a resource without needing to change the bytecode format itself. But that’s a whole other discussion.

5

Yes absolutely! It is possible that we end up with a solution that naturally does not break backward compatibility. My approach here is just to try to address it before claiming stability just so that we don’t constraint the development of the lazy-loading solution with the compatibility problem!

6

+1. It’s nice to design some important components without yet shackling any kind of compatibility guarantees. This is one of the reasons why I specifically delayed this during the initial bytecode proposals.

7

Created tracker issue to make easier to coordinate.