IR serialization/deserialization.

[eddyb]

This would be needed for e.g. Rust-GPU to store SPIR-T on disk from compiling library crates, without relying on SPIR-V.

Additionally, any features that SPIR-V may be lossy with, will need serializing the SPIR-T itself.

Some amount of versioning will be required to avoid mistakenly trying to read back an outdated format

• versioning could be manual, or based on the shape of types using proc-macro derives
  • maybe even e.g. serde with a weird deserializer?
  • one of the sillier options is a build script that hashes the source code, but that seems:
  • not sufficient: cannot account for dependencies, only src/ contents
  • not necessary (or "overly conservative"): any change will trigger a build script rerun
• partially alleviated by #2 (but that doesn't account for valid-seeming IR that's a result of an accidental overlap)

[bjorn3]

Cranelift has a VersionMarker ZST which serializes as the version and on deserialization checks that it matches the version and otherwise gives an error. See https://docs.rs/cranelift-codegen/0.89.2/src/cranelift_codegen/ir/function.rs.html#38-66 The version is computed based on the cargo package version and for git repos the current commit. If you change something without committing, the build script won't rerun.

[eddyb]

One way to avoid the cost of hashing the source/recomputing a schema/etc. every build, would be to just make this feature optional (at the Cargo package level), and not turn it on during development, while still testing it in CI, and having it enabled by e.g. Rust-GPU.

That way, we wouldn't even need any separate files computed from the source code with a manual step (or worse, manually edited schemas), even if something like that might still be desirable long-term if we ever want to have any kind of back-compat guarantee.

---

Another issue is we can't serialize/deserialize to/from the actual Context-allocated interned/entity IDs, and we need Context (for interned defs) and Module/FuncDefBody (for various EntityDefs).

So we might still have to provide our own serialization proc macros, or even use diplomat_core in the build script to extract a "schema"/"IDL", that can special-case various generic types (e.g. Module and FuncDefBody each act as "entity universes" for specific entity types, but the only way that's currently signaled is their EntityDefs fields).