Skip to content

hipRTC cache: capture #include content via preprocessing (#1335) - #1375

Merged
pvelesko merged 1 commit into
mainfrom
fix-hiprtc-cache-includes-v2
Jul 30, 2026
Merged

hipRTC cache: capture #include content via preprocessing (#1335)#1375
pvelesko merged 1 commit into
mainfrom
fix-hiprtc-cache-includes-v2

Conversation

@pvelesko

@pvelesko pvelesko commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

Supersedes #1338 (squashed, rebased, original work by @Noerr).

Keys the hipRTC cache on the preprocessed TU so #included header content invalidates it.

Also fixes three latent bugs this exposed: hipcc treated -E/-S as a link so chip-kernel-verify ran on preprocessed output and crashed; extractSPIRVModule walked bundle descriptors unbounded; processOptions ran only on cache miss, leaving hiprtcGetProgramLog empty on a hit.

Needs CHIP-SPV/HIPCC branch fix-preprocess-only-not-link (bumped here).

Local: dgpu level0 970/970, dgpu opencl 969/969.

Fixes #1335

computeHiprtcCacheKey() keyed on the raw HIP source, so it never saw the
content of headers pulled in by #include, in particular headers resolved
from -I filesystem paths. Editing such a header did not change the key, so
a stale, previously cached SPIR-V was served silently.

When the source may include headers, preprocess it and key on the
preprocessed translation unit. A conservative scan skips the preprocess for
self-contained sources, where the raw source is already a complete key.

Fixing this exposed three latent bugs that had to be resolved for it to
work at all:

  * hipcc never set compileOnly for -E/-S/-fsyntax-only, so it treated them
    as link invocations: it appended link flags and ran the post-link
    chip-kernel-verify pass on output that is not a final image.
    Preprocessed HIP is a *textual* offload bundle whose delimiter comments
    contain the literal __CLANG_OFFLOAD_BUNDLE__, which the SPIR-V
    extractor mistook for the binary bundle magic and then parsed as a
    bundle header, crashing. Only hosts with ocloc got far enough to see
    it, which is why this looked like a compiler bug on the Intel runners.

  * extractSPIRVModule() walked the bundle descriptors using counts and
    sizes read out of the buffer with no bound on the buffer itself. It now
    takes an optional size and rejects out-of-range descriptors, and
    chip-kernel-verify skips textual bundles outright.

  * processOptions() ran only on the cache-miss path, but it is also what
    records "warning: ignored option" in the program log. On a cache hit
    hiprtcGetProgramLog() therefore came back empty, making the log depend
    on cache state (TestHiprtcOptions passed against a cold cache and
    failed on every run after). It is now called once, before the cache
    lookup, which also stops the preprocess pass from logging the same
    warning twice.

Tests: TestHiprtcCacheIncludes asserts that -I header content participates
in the key (miss / hit / miss on edit / hit on revert).
TestHiprtcCacheProgramLog asserts the program log is identical on cache hit
and miss and that diagnostics are not duplicated. Both run through a
wrapper that provisions a guaranteed-empty cache per run.

Requires the HIPCC submodule bump in this commit (CHIP-SPV/HIPCC#11,
now merged to HIPCC main) for the -E/-S fix.

Fixes #1335

Co-authored-by: Paulius Velesko <pvelesko@pglc.io>
@pvelesko
pvelesko force-pushed the fix-hiprtc-cache-includes-v2 branch from 47b2a0f to 8546eb5 Compare July 30, 2026 04:10
@pvelesko
pvelesko merged commit 4930f15 into main Jul 30, 2026
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

hipRTC cache does not consider changes to filesystem #include content from source pre-processing

2 participants