LLVM bitcode cache reuse across toolchain version boundaries

LLVM emits bitcode as an intermediate representation that can be written and read by the compiler infrastructure, but the project does not guarantee forward or backward compatibility between releases. A file produced by one version may be rejected by an older reader, while a newer reader may parse older bitcode with warnings or loss of version-specific detail. There is no published stable archival format or compatibility matrix, so reader and writer support is implementation-defined and version-sensitive.

For a build system that caches artifacts keyed by source content, the unresolved decision is which additional cache-key constraints are sufficient to avoid loading incompatible bitcode across an LLVM upgrade. The exact boundary where a producer version and a consumer version diverge is not documented in a general contract and must be discovered per release.

What is the minimal set of cache-key dimensions—such as exact LLVM version, target triple, and relevant flags—required to safely reuse bitcode across a toolchain upgrade? Are there specific bitcode encoding changes introduced between releases that reliably cause older disassemblers or optimizers to fail, and where should they be checked before deployment? Should cross-version bitcode loading be treated as an unsupported operation requiring explicit per-release validation rather than a configurable policy?