Background

#183856 landed a single-config hotfix for the ~99% conv2d FP16 perf regression on Windows + ROCm (gfx1150) tracked in #183853 / ROCm/TheRock#5157. The hotfix moves -O3 -DNDEBUG (and the other per-config flags) out of CMAKE_HIP_FLAGS_<CONFIG> and into CMAKE_HIP_FLAGS, gated on CMAKE_BUILD_TYPE. That restored the optimization level on the Windows ROCm Ninja build that PyTorch CI actually uses, but it does not address the underlying bug. This issue tracks the proper fix.

Why the merged change is a workaround

In cmake/public/LoadHIP.cmake the Windows path overrides the HIP compile rule template:

set(CMAKE_HIP_COMPILE_OBJECT
  "<CMAKE_HIP_COMPILER> <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -x hip -c <SOURCE>")

CMake's default rule writer concatenates CMAKE_HIP_FLAGS and CMAKE_HIP_FLAGS_<CONFIG> into the FLAGS ninja variable that <FLAGS> expands to. Overriding CMAKE_HIP_COMPILE_OBJECT replaces that rule-generation machinery, and on this code path CMAKE_HIP_FLAGS_<CONFIG> no longer reaches <FLAGS> (verified via the generated build.ninja). The merged fix sidesteps this by writing the per-config flags directly into CMAKE_HIP_FLAGS once CMAKE_BUILD_TYPE is known.

Consequences of leaving the root cause unfixed:

• Multi-config generators are not fixed. The if(NOT CMAKE_CONFIGURATION_TYPES) guard correctly avoids baking a single config's flags into a multi-config build tree (Visual Studio, Ninja Multi-Config), but those generators still receive no per-config HIP optimization flags. PyTorch's Windows ROCm CI uses single-config Ninja, so this is latent rather than active.
• Any other CMAKE_HIP_FLAGS_<CONFIG> contribution is silently dropped. Anything downstream that appends to CMAKE_HIP_FLAGS_RELEASE (e.g. a user-supplied toolchain file, a future PyTorch change, or a CMake module that sets per-config defaults) will not take effect on the Windows HIP compile line.
• The override drifts away from CMake's intended model. As CMake's native HIP support evolves, this divergence will keep accumulating special cases.

Possible proper fixes

In rough order of preference:

1. Stop overriding CMAKE_HIP_COMPILE_OBJECT entirely. Investigate which combination of platform variables (CMAKE_HIP_COMPILER_FRONTEND_VARIANT, include-flag variables, depfile-format variables, MSVC runtime mappings, ...) causes the Windows-Clang-HIP platform module to emit GNU-style rules directly. If that is achievable, the per-config flags flow through CMake's normal pipeline and the multi-config case works too.
2. Keep the override but route per-config flags through it. Expand ${CMAKE_HIP_FLAGS_${CMAKE_BUILD_TYPE}} (single-config) or the appropriate per-config equivalent into the template. This is still a workaround; it does not fix multi-config without additional plumbing.
3. File the underlying issue upstream against CMake if (1) turns out to require a CMake-side change. The current override exists because Windows-Clang-HIP.cmake emits MSVC-style rules that clang++ (GNU frontend) for HIP rejects; if that platform module needs to grow GNU-frontend support, that work belongs in upstream CMake.

Validation

Whatever the fix, it should:

• Restore conv2d FP16 perf on gfx1150 (the regression in #183853) on a clean Windows ROCm build with no per-config flag injection in CMAKE_HIP_FLAGS.
• Verify by inspecting the generated build.ninja that -O3 -DNDEBUG (Release) appears in the FLAGS variable used by the HIP compile rule via CMake's standard mechanism, not via direct injection into CMAKE_HIP_FLAGS.
• Spot-check a multi-config generator if one is reachable in CI or locally (Ninja Multi-Config is the cheapest).

References

• Merged hotfix: #183856
• Original regression report: #183853
• Downstream report: ROCm/TheRock#5157
• PRs that introduced the custom compile rule: #180485, #183365
• PR comment thread where this follow-up was agreed: https://github.com/pytorch/pytorch/pull/183856#issuecomment-4470855554

cc @malfet @peterjc123 @mszhanyi @skyline75489 @nbcsm @iremyux @Blackhex @nkhasbag-nv @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @jataylo @hongxiayang @naromero77amd @pragupta @jerrymannil @xinyazhang @adityas-amd @astrelsky @jeffdaily