Specialize std::numeric_limits for dace::half and dace::bfloat16 - #2485
Open
ThrudPrimrose wants to merge 1 commit into
Open
Specialize std::numeric_limits for dace::half and dace::bfloat16#2485ThrudPrimrose wants to merge 1 commit into
ThrudPrimrose wants to merge 1 commit into
Conversation
The primary std::numeric_limits template answers max() == lowest() == infinity() == T() -- zero -- for unspecialized class types, so code that seeds a min/max reduction identity from it silently produces zeros instead of failing to compile. Add the binary16 and bfloat16 specializations to the CPU low-precision structs, with static_asserts pinning the max() and denorm_min() bit patterns.
ThrudPrimrose
marked this pull request as ready for review
August 10, 2026 09:32
tbennun
requested changes
Aug 11, 2026
tbennun
left a comment
tbennun
left a comment
Collaborator
There was a problem hiding this comment.
I like it but needs (1) to look at the nit; (2) end-to-end regression test that caused this PR to exist.
Comment on lines
+349
to
+352
| DACE_LP_LIMITS(half, 11, 3, 5, -13, -4, 16, 4, true, 6.5504e+4f, 6.103515625e-05f, 9.765625e-04f, | ||
| 5.9604644775390625e-08f); | ||
| DACE_LP_LIMITS(bfloat16, 8, 2, 4, -125, -37, 128, 38, false, 3.38953139e+38f, 1.17549435e-38f, 7.8125e-03f, | ||
| 9.18354962e-41f); |
Collaborator
There was a problem hiding this comment.
why add the f suffix when these are cast to the data type anyway?
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
2 participants
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.
The primary
std::numeric_limitstemplate answersmax() == lowest() == infinity() == T()for any unspecialized class type, i.e. zero fordace::halfanddace::bfloat16. Code that seeds a min/max reduction or scan identity fromstd::numeric_limits<T>therefore still compiles and silently produces zeros --dace/libraries/torch/dispatchers/cpp_torch_extension.pyemits exactlystd::numeric_limits<{dtype.ctype}>::infinity()for that purpose. We hit this as a min-scan over fp16 returning all zeros.This adds
<limits>plus thestd::numeric_limitsspecializations for the two 16-bit low-precision structs, withstatic_asserts pinningmax()anddenorm_min()to the IEEE binary16 / bfloat16 bit patterns so a typo in a literal cannot pass as a plausible-looking value. The block is excluded under__CUDACC__/__HIPCC__, wheredace::half/dace::bfloat16are the vendor native types instead. The fp8 structs in the same header are left alone here to keep the diff minimal.tests/codegen/lowp_numeric_limits_test.pycompiles and runs a probe againstdace/runtime/include; every check compares against a value the primary template cannot produce, so the probe exits 1 onmainand 0 with this change. The new header code is warning-free underg++andclang++at-Wall -Wextra -Wpedantic -Werror.🤖 Generated with Claude Code