[Mlir-commits] [mlir] [mlir][RFC] Bytecode: op fallback path (PR #129784)

[River Riddle]

River707 wrote:

I took a look over and I have a few concerns about the approach here. This seems to be trying to handle a very specific situation, but I don't think it's fully correct. The op not being understood is one aspect, but you can't directly grab data from the bytecode and rely on that being able to roundtrip (the bytecode has references to different parts of itself that you won't be able to replicate and understand). The easiest example here is what to do about new attributes/types that weren't present in an older dialect, if that attribute/type uses a custom encoding you can't take the bytecode for it directly and roundtrip it. I also don't want to encorage trying to make expectations on the structure of bytecode or how things are referenced. Consider a new container attribute `#foo.new_container<#foo.old_attr>`, if `foo.new_container` uses a custom dialect representation (which is generally the encouraged/expected case), you won't know how to interpret its contents (to know that its referencing `#foo.old_attr`). There is no way that you will reasonably be able to roundtrip this without essentially keeping entire sections of the original bytecode alive.

https://github.com/llvm/llvm-project/pull/129784