Summary
On Windows (MSVC), every hotswap apply function in Comgr silently returns 0 — WMMA hazard patching, VOP3PX2 SRC2 fix, in-place / trampoline / scratch / split patches, and the DWARF/debug-info patches are all no-ops. The library compiles and links cleanly; calls just don't do anything.
Root cause
comgr-hotswap-b0a0.cpp provides default implementations gated by LLVM_ATTRIBUTE_WEAK:
LLVM_ATTRIBUTE_WEAK uint32_t applyWmmaHazardPatch(PatchContext &) { return 0; }
LLVM_ATTRIBUTE_WEAK uint32_t applyVop3px2Src2Fix(PatchContext &) { return 0; }
// ... 4 more apply* + several liveness/DWARF stubs ...The "real" implementations live in sibling files (comgr-hotswap-patch-wmma-hazard.cpp, comgr-hotswap-patch-vop3px2-src2.cpp, comgr-hotswap-patch-trampoline.cpp, comgr-hotswap-patch-inplace.cpp) and are designed to be strong-symbol overrides at link time.
But on Windows LLVM_ATTRIBUTE_WEAK expands to nothing (per llvm/include/llvm/Support/Compiler.h — there's even a FIXME: Provide this for PE/COFF targets comment). That makes the b0a0.cpp definitions plain strong symbols. To avoid duplicate-symbol link errors, the strong overrides in the sibling files are wrapped in #if !defined(_MSC_VER) and excluded from the build.
End result: only the no-op fallbacks reach the linker → all apply calls return 0 → hotswap as a feature is silently disabled.
Discovered via
Standing up Windows CI for the SPIRV CI workflow on ROCm/SPIRV-LLVM-Translator (#196). HotswapMCTests failed to link on Windows with LNK2019: unresolved external symbol classifyWmmaNops / patchScaleSrc2. Tracing that surfaced the broader picture above.
Question for the HotSwap team
Is hotswap supposed to work on Windows?
Summary
On Windows (MSVC), every hotswap apply function in Comgr silently returns 0 — WMMA hazard patching, VOP3PX2 SRC2 fix, in-place / trampoline / scratch / split patches, and the DWARF/debug-info patches are all no-ops. The library compiles and links cleanly; calls just don't do anything.
Root cause
comgr-hotswap-b0a0.cppprovides default implementations gated byLLVM_ATTRIBUTE_WEAK:The "real" implementations live in sibling files (
comgr-hotswap-patch-wmma-hazard.cpp,comgr-hotswap-patch-vop3px2-src2.cpp,comgr-hotswap-patch-trampoline.cpp,comgr-hotswap-patch-inplace.cpp) and are designed to be strong-symbol overrides at link time.But on Windows
LLVM_ATTRIBUTE_WEAKexpands to nothing (perllvm/include/llvm/Support/Compiler.h— there's even aFIXME: Provide this for PE/COFF targetscomment). That makes the b0a0.cpp definitions plain strong symbols. To avoid duplicate-symbol link errors, the strong overrides in the sibling files are wrapped in#if !defined(_MSC_VER)and excluded from the build.End result: only the no-op fallbacks reach the linker → all apply calls return 0 → hotswap as a feature is silently disabled.
Discovered via
Standing up Windows CI for the SPIRV CI workflow on
ROCm/SPIRV-LLVM-Translator(#196).HotswapMCTestsfailed to link on Windows withLNK2019: unresolved external symbol classifyWmmaNops / patchScaleSrc2. Tracing that surfaced the broader picture above.Question for the HotSwap team
Is hotswap supposed to work on Windows?