mirror of
https://github.com/compiler-explorer/compiler-explorer.git
synced 2026-05-16 10:12:38 -04:00
0c21e98bbb
NVCC embeds the raw CUDA fat binary blob in the host-side x86 assembly inside a `#APP`/`#NO_APP` inline-assembly block under the label `fatbinData`. In a realistic kernel this can be 100+ lines of `.quad` hex values — a wall of noise before any user-readable code. The fix adds a per-compiler pre-processing step in `NvccCompiler`: before the host assembly is passed to the ASM parser, any `#APP`/`#NO_APP` block that contains a `.nv_fatbin` section is stripped out entirely. Only those blocks are removed; genuine user inline-assembly blocks (which also use `#APP`/`#NO_APP` but do not contain `.nv_fatbin`) are left intact. This approach is intentionally NVCC-specific (in `NvccCompiler`, not the base `AsmParser`) so there is no risk of false positives for other compilers. The blob is stripped before `findUsedLabels` runs, so the `fatbinData` label naturally disappears as unreferenced without needing any special-casing in the parser's label-filtering logic. Filtering is gated on the existing Labels filter, matching user expectations: with no filters active everything is visible; with the Labels filter on the fat binary blob disappears. Testing: - `test/compilers/nvcc-tests.ts` — five unit tests for `removeNvccFatbinaryBlob()`: strips fat-binary blocks, preserves user inline-asm blocks, handles multiple mixed blocks, no-op with no APP blocks, gracefully handles malformed unclosed blocks. - `test/filters-cases/nvcc-x86-host-example.asm` — representative NVCC 12.0 host assembly (real 15-line fat binary, boilerplate functions, `.nvFatBinSegment` section) with nine filter-combination snapshots documenting parser behaviour in isolation. Closes #5178 🤖 Generated by LLM (Claude, via OpenClaw)