cicc re-runs when only line positions change, and emits identical PTX

Not a bug report - an ask about whether an opt-in for this would be welcome.

cicc's input is the preprocessed device file, which records where in its source each piece of the translation unit came from. A preprocessor pads a small gap with blank lines but re-anchors with a #line directive when it returns from a nested include. So editing a comment in a header, if it changes the line count, moves a blank line and every directive below it, and cicc recompiles - then emits byte-identical PTX. ptxas keeps hitting, because its own input did not change, which is what makes the wasted work visible.

On a CUDA project of ~370 objects (CUDA 12.8, MSVC 2022, ninja), a header comment edit that changes line count cost 79.8s at 60.9% hits, against 24s at 100% when the edit held the line count. All the misses were cicc and device code; ptxas and the host pass were already at 100%.

Hashing that input with blank lines dropped and #line numbers zeroed collapses the two hashes, and takes the same edit to 27.7s with cicc at 23/23 hits. The object from such a hit is byte-identical to a fresh compile.

The obvious objection is that it makes two textually different inputs share an entry, so a hit can replay a warning whose line number belongs to the other file. That is why I would only propose it opt-in and default off, guarded by an allowlist of cicc flags known not to make line positions observable - a denylist is not enough, since nvcc --source-in-ptx reaches cicc as -show-src with no -generate-line-info beside it.

Implementation on https://github.com/beru/sccache/tree/cicc-blank-line-hash if it is of interest. Entirely understand if the cache-key tradeoff is not one the project wants.

Generated with Claude Code