LLVM LTO Cache vs. Source File Modifications – Interoperability Concern

Goal

Ensure that any change to a source file that is part of an LTO module is reflected in the final binary, without relying on manual cache deletion.

Constraints & Uncertainty

• LTO builds a cache keyed by the module’s bitcode hash and the compiler flags used at link time.
• When a source file changes but the bitcode hash or flags remain the same, the cache may still be reused, producing a stale binary.
• No automatic invalidation exists in current LLVM releases; the cache is only purged on user‑initiated delete or forced rebuild.
• LLVM community discussions have suggested adding file timestamps or content hashes to the key, but no official change has been merged.

Questions

1. Does LLVM LTO currently support incorporating file timestamps or content hashes into the cache key to detect stale source changes?
2. What compiler or build flags, if any, can be used to force LTO cache invalidation on source modification?
3. Is there a documented mechanism to programmatically inspect or invalidate specific LTO cache entries without a full rebuild?