jpienaar wrote: > > To be able to flag incompatible bytecode files rather than have it fail > > later in mysterious ways. E.g., allows for a more strict failure. > > That would require some sort of principles and policy around the changes that > affect the serialization of this and the maintenance of this version number, > I haven't seen a discussion about this: did I miss it? > > Also, TOSA isn't a hermetic dialect: it includes other IR entities from other > dialects, and changing these would impact this story as well.
I think you are assuming guarantees here that doesn't exist. This is best effort, allows for it/but doesn't make it happen nor enforcement or any such. Primarily around TOSA ops and which builtin dialect attributes are used. E.g., "bump this if you discover you also need a atomic change TF repo side" kind of level: this doesn't remove the need for the change TF repo side along with LLVM revision bump, but this does allow for folks using TF via pip and TOSA ingestion as well to have a binary interop that keeps working. No requirement being placed on community. While allowing folks that care about enabling such cases to have it working. So this is a mechanism with policy TBD. > IR entities from other dialects Correct changing builtin dialect serialization would affect this. I think we should consider enabling detecting that indeed. If the builtin dialect serialization changes, one could get some really random results :) Even considered tying those to the bytecode version itself given the impact a change could have. That is a good discussion to have but separate from this. https://github.com/llvm/llvm-project/pull/79514 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
