Support forward-mode differentiation on Kokkos 5. - #1914
Open
vgvassilev wants to merge 1 commit into
Open
Conversation
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
vgvassilev
force-pushed
the
clad-kokkos5-forward
branch
from
July 21, 2026 01:23
506839f to
b8ac4c3
Compare
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
Kokkos 5 constructs a View from a label and its runtime extents through a
variadic constructor, so clad passes the label and written extents to
constructor_pushforward. The overload for the fixed eight-index Kokkos 4
constructor no longer matches, so the generic fallback built the tangent as
View(derived-label, derived-extent) == View("", 0) -- an extent-0 View. Its
element accesses were out of bounds, and a function constructing two Views
corrupted the host allocator and aborted at the second allocation. Add
constructor_pushforward overloads for the rank-1 and rank-2 Kokkos 5 forms so
the tangent is an independent, identically shaped View; the Kokkos 4 overload
is kept, and higher runtime ranks would need analogous overloads.
An all-static-extent View (every extent a compile-time template argument, e.g.
View<double[5]> or View<double[2][2][2][2][2][2][2]>) is constructed from a
label alone, so clad passes only the label -- which none of the extent-carrying
overloads accept. clad then fell back to a direct tangent construction that
flattens the label's implicit std::string temporary into a View braced-init,
View{"name", allocator}, for which no constructor exists. Add a label-only
constructor_pushforward so clad emits a proper pushforward call instead.
Two supporting changes: Derive read FunctionDecl::getName() to special-case a
few builtins on a declaration-only callee, which asserts on the non-identifier
name of an operator -- reached via a KOKKOS_LAMBDA's operator(); take the name
only when it is an identifier. And link the imported Kokkos::kokkos target in
the unit tests so its cxx_std_20 usage requirement, which Kokkos 5 needs,
propagates.
Provision the *-kokkos CI rows with Kokkos 5.1.1 from the ci-workflows
setup-kokkos action instead of libtrilinos-kokkos-dev (an unusable Trilinos 3.4
bundle). Reverse mode over a View is not yet supported on Kokkos 5 -- TBR
analysis asserts on a View access, and reverse over a View construction hits an
upstream clang cast<TagType> assertion -- so the reverse checks in ViewAccess
and ViewBasics are disabled with a note; the forward tangents stay and are
checked against finite differences (ViewCtorForward.cpp: rank-1, rank-2 and the
compound-assignment ViewAccess::f shape). DeclOnlyOperator.cpp covers the
getName change without Kokkos.
With the forward TUs compiling, the KokkosTests target now links as a whole,
which exposed an existing one-definition-rule violation: TestUtils.h defined the
non-inline free function parallel_polynomial_true_derivative, so every including
TU emitted a separate definition. Mark it inline.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
vgvassilev
force-pushed
the
clad-kokkos5-forward
branch
from
July 21, 2026 12:33
b8ac4c3 to
aa4253b
Compare
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
1 participant
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.
Kokkos 5 constructs a View from a label and its runtime extents through a variadic constructor, so clad passes the label and written extents to constructor_pushforward. The overload for the fixed eight-index Kokkos 4 constructor no longer matches, so the generic fallback built the tangent as View(derived-label, derived-extent) == View("", 0) -- an extent-0 View. Its element accesses were out of bounds, and a function constructing two Views corrupted the host allocator and aborted at the second allocation. Add constructor_pushforward overloads for the rank-1 and rank-2 Kokkos 5 forms so the tangent is an independent, identically shaped View; the Kokkos 4 overload is kept, and higher runtime ranks would need analogous overloads.
Two supporting changes: Derive read FunctionDecl::getName() to special-case a few builtins on a declaration-only callee, which asserts on the non-identifier name of an operator -- reached via a KOKKOS_LAMBDA's operator(); take the name only when it is an identifier. And link the imported Kokkos::kokkos target in the unit tests so its cxx_std_20 usage requirement, which Kokkos 5 needs, propagates.
The rank-1, rank-2 and ViewAccess::f (compound-assignment) forward gradients match central finite differences. Tests: test/Regressions/DeclOnlyOperator.cpp, unittests/Kokkos/ViewCtorForward.cpp -- the latter runs once the KokkosTests target builds, which reverse-mode View gaps still block.