Reshape: guard the 9.22 reshape-mode attribute at runtime, not just at compile time - #466
Merged
Anerudhan merged 1 commit intoJul 31, 2026
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughReshape operation creation gates mode attribute configuration on the cuDNN runtime version. Older runtimes support view-only reshapes without the attribute and reject logical reshapes. Runtimes 9.22 and newer retain explicit mode configuration. ChangesReshape runtime compatibility
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…t compile time
CUDNN_ATTR_OPERATION_RESHAPE_MODE is set under `#if (CUDNN_VERSION >= 92200)`
alone. The compile-time guard is necessary -- cudnnBackendReshapeMode_t and the
attribute only exist in >= 9.22 headers -- but not sufficient: a frontend built
against >= 9.22 headers and run against an older runtime sets an attribute that
runtime does not know, and the failure takes down every graph containing a
Reshape node. In practice that is all of sdpa_backward:
RuntimeError: detail::set_attribute(reshape_operation.get_raw_desc(),
CUDNN_ATTR_OPERATION_RESHAPE_MODE, CUDNN_TYPE_RESHAPE_MODE, 1,
&cudnn_reshape_mode) failed
Observed on 9.18 / 9.19 / 9.20 / 9.21 runtimes with an FE built against 9.26
headers; forward is unaffected. Rebuilding the identical FE source against 9.18
headers turns 20/44 SDPA cases into 40/44, and that 9.18-header FE then runs
against the 9.26 runtime with identical numerics -- i.e. the attribute is the
only thing at issue.
Fix: nest a runtime check inside the existing compile-time guard, matching the
idiom already at reduction.h:96-97. plan_helpers.h:80 and Heuristics.h:236 have
the same unconditional shape, but only at the 9.08 floor, where a runtime that
old paired with modern headers is already outside support; 9.22 vs 9.18-9.21 is
inside the range consumers run (PyTorch's varlen floor is 91800).
Skipping the attribute on an older runtime reproduces that runtime's behaviour
exactly: pre-9.22 reshape has a single semantics and it is the view-only one
(CUDNN_RESHAPE_VIEW_ONLY == 0, "no data movement"), which is also this
frontend's default. An explicit LOGICAL request cannot be honoured there and
silently downgrading it would change results, so that returns
GRAPH_NOT_SUPPORTED.
NV_CUDNN_FE_DYNAMIC_CHECK_CUDNN_BACKEND_VERSION is deliberately not reused: it
expands to nothing unless NV_CUDNN_FRONTEND_USE_DYNAMIC_LOADING is defined
(cudnn_frontend_shim.h:213-215), so it would be a no-op in an ordinary C++
build -- exactly the configuration this protects. The same caveat applies to
sites that do use the macro, e.g. transpose.h:99; not addressed here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
YangXu1990uiuc
force-pushed
the
yanxu/fe-reshape-runtime-guard-gh
branch
from
July 31, 2026 20:38
504e34e to
3ff9747
Compare
Anerudhan
self-requested a review
July 31, 2026 23:20
Anerudhan
approved these changes
Jul 31, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CUDNN_ATTR_OPERATION_RESHAPE_MODEis set under#if (CUDNN_VERSION >= 92200)alone(
node/reshape.h:109). The compile-time guard is necessary but not sufficient: a frontend builtagainst >= 9.22 headers and run against an older runtime sets an attribute that runtime does not
know, and the failure takes down every graph containing a Reshape node — in practice all of
sdpa_backward, on 9.18 / 9.19 / 9.20 / 9.21.Fix: nest a runtime check inside the existing compile-time guard, the idiom already used at
node/reduction.h:96-97.Two decisions that aren't obvious from the diff:
LOGICALis rejected rather than silently skipped. Not setting the attribute reproduces an oldruntime's behaviour exactly, because pre-9.22 reshape has one semantics and it is the view-only one
(
CUDNN_RESHAPE_VIEW_ONLY == 0, "no data movement") — also this frontend's default. But anexplicit
LOGICALrequest cannot be honoured there, and downgrading it to view-only would changeresults, so it returns
GRAPH_NOT_SUPPORTED.The check is spelled out instead of using
NV_CUDNN_FE_DYNAMIC_CHECK_CUDNN_BACKEND_VERSION.That macro expands to nothing unless
NV_CUDNN_FRONTEND_USE_DYNAMIC_LOADINGis defined(
cudnn_frontend_shim.h:213-215), so it would be a no-op in an ordinary C++ build — the exactconfiguration this needs to protect. Same caveat applies to sites that do use the macro
(e.g.
node/transpose.h:99); not addressed here.g++ -fsyntax-only -std=c++17clean;clang-formatclean (pre-commit passed).Summary by CodeRabbit