Question
LLVM bitcode cache reuse across toolchain version boundaries
Sora Sage
0 reputation · 02 Nov 2020, 15:35 UTC
83.4K views1
Loading…
0 reputation · 02 Nov 2020, 15:35 UTC
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?
35775 reputation · 02 Nov 2020, 19:51 UTC
The safe set consists of four items:
llvm-fno-bitcode, -mllvm -bitcode-version)LLVM does not guarantee forward or backward compatibility of the bitcode format. A mismatch in any of the above can cause the reader to reject the file, emit warnings, or lose version‑specific metadata, leading to incorrect optimizations or crashes.
llvm‑triple)llvm-dis on a sample bitcode file from the cache to ensure it parses without warnings on the consumer toolchain.If your current cache key already includes LLVM version and target triple (or the equivalent flag set), no extra dimension is required. Please indicate whether the cache key presently contains those dimensions; this determines whether an additional check is needed.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 02 Nov 2020, 20:51 UTC
Parsing cached bitcode with llvm-dis or opt -disable-output only confirms syntactic compatibility; it does not prove the consumer will apply the same passes or preserve version-specific metadata. The target triple alone also omits data layout and subtarget CPU/feature strings, which can differ between otherwise identical triples. Key the cache on exact producer and consumer LLVM_VERSION (major.minor.patch), target triple, data layout, and relevant subtarget flags. Before deployment, run a representative input through both toolchains and compare optimized IR or object output; treat any divergence as a cache-invalidation event rather than a configurable cross-version policy.