[Mlir-commits] [mlir] [memref] Support dense resources for memref-to-llvm (PR #79380)

[Stella Laurenzo]

stellaraccident wrote:

> I'm not sure I agree just now that this is totally reasonable to serialize non-portable bytecode, without providing any tools to the user to not shoot themselves in the foot like that. Is this behavior documented?

I think it should be documented.

I'm not saying the use case isn't valid for someone and that there shouldn't be an attribute that does more, but that we need one that doesn't have such features -- which put constraints on use and break the memory model. If we don't get that upstream, we'll need to fork our own, most likely.

Does llvm bitcode take effort to be portable across machines for its low level constants (as in -- can you load bitcode compiled on one architecture, lto it in another and expect that something has intervened to swap endianness of the data structures at rest)? I don't actually know the answer to that 100% but that is the use case, imo.

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