Add implementations for the C++ standard library math #551
Conversation
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
AlexVlx
requested review from
RobsonRLemos,
lawruble13,
stanleytsang-amd and
umfranzw
as code owners
Contributor
Author
|
The corresponding LLVM change is here llvm/llvm-project#140158. |
Collaborator
stanleytsang-amd
left a comment
stanleytsang-amd
left a comment
There was a problem hiding this comment.
@AlexVlx changes look fine to me, but you'll need to rebase your PR/fix merge conflicts for this one as well.
Contributor
|
Please resolve merge conflicts or close this PR to complete the task of importing PRs from this repo to the monorepo. |
Contributor
|
Closing the pull request in this repo. Please refer to the migrated pull request for updates. |
stanleytsang-amd
pushed a commit
to ROCm/rocm-libraries
that referenced
this pull request
Jun 3, 2025
The C++ standard library, as well as generic C++ code, use [special compiler builtins](https://gcc.gnu.org/onlinedocs/gcc/Library-Builtins.html) to implement math functions. Some of these have non-trivial lowerings and are not handled in the compiler, which leads to rather opaque arcane errors obtaining when compiling code in `--hipstdpar` mode, wherein they end up directly consumed. This patch adds a header that forwards to the ROCDL implementations via an uniform HIPSTDPAR interface. A corresponding patch in the compiler will handle forwarding the builtins that we cannot directly lower to said uniform HIPSTDPAR interface. With this design, it is possible to provide alternative implementations, and it is also possible for the user to provide their own implementations if e.g. they are compiling with `-nogpuinc` and / or `-nogpulib`. --- 🔁 Imported from [ROCm/rocThrust#551](ROCm/rocThrust#551) 🧑💻 Originally authored by @AlexVlx --------- Co-authored-by: Alex Voicu <[email protected]> Co-authored-by: assistant-librarian[bot] <assistant-librarian[bot]@users.noreply.github.com>
jayhawk-commits
pushed a commit
to ROCm/rocm-libraries
that referenced
this pull request
Jun 17, 2025
The C++ standard library, as well as generic C++ code, use [special compiler builtins](https://gcc.gnu.org/onlinedocs/gcc/Library-Builtins.html) to implement math functions. Some of these have non-trivial lowerings and are not handled in the compiler, which leads to rather opaque arcane errors obtaining when compiling code in `--hipstdpar` mode, wherein they end up directly consumed. This patch adds a header that forwards to the ROCDL implementations via an uniform HIPSTDPAR interface. A corresponding patch in the compiler will handle forwarding the builtins that we cannot directly lower to said uniform HIPSTDPAR interface. With this design, it is possible to provide alternative implementations, and it is also possible for the user to provide their own implementations if e.g. they are compiling with `-nogpuinc` and / or `-nogpulib`. --- 🔁 Imported from [ROCm/rocThrust#551](ROCm/rocThrust#551) 🧑💻 Originally authored by @AlexVlx --------- Co-authored-by: Alex Voicu <[email protected]> Co-authored-by: assistant-librarian[bot] <assistant-librarian[bot]@users.noreply.github.com>
AlexVlx
added a commit
to llvm/llvm-project
that referenced
this pull request
Jul 28, 2025
When compiling in `--hipstdpar` mode, the builtins corresponding to the standard library might end up in code that is expected to execute on the accelerator (e.g. by using the `std::` prefixed functions from `<cmath>`). We do not have uniform handling for this in AMDGPU, and the errors that obtain are quite arcane. Furthermore, the user-space changes required to work around this tend to be rather intrusive. This patch adds an additional `--hipstdpar` specific pass which forwards to the run time component of HIPSTDPAR the intrinsics / libcalls which result from the use of the math builtins, and which are not properly handled. In the long run we will want to stop relying on this and handle things in the compiler, but it is going to be a rather lengthy journey, which makes this medium term escape hatch necessary. The paired change in the run time component is here <ROCm/rocThrust#551>.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jul 28, 2025
When compiling in `--hipstdpar` mode, the builtins corresponding to the standard library might end up in code that is expected to execute on the accelerator (e.g. by using the `std::` prefixed functions from `<cmath>`). We do not have uniform handling for this in AMDGPU, and the errors that obtain are quite arcane. Furthermore, the user-space changes required to work around this tend to be rather intrusive. This patch adds an additional `--hipstdpar` specific pass which forwards to the run time component of HIPSTDPAR the intrinsics / libcalls which result from the use of the math builtins, and which are not properly handled. In the long run we will want to stop relying on this and handle things in the compiler, but it is going to be a rather lengthy journey, which makes this medium term escape hatch necessary. The paired change in the run time component is here <ROCm/rocThrust#551>.
Sterling-Augustine
pushed a commit
to Sterling-Augustine/llvm-project
that referenced
this pull request
Jul 29, 2025
When compiling in `--hipstdpar` mode, the builtins corresponding to the standard library might end up in code that is expected to execute on the accelerator (e.g. by using the `std::` prefixed functions from `<cmath>`). We do not have uniform handling for this in AMDGPU, and the errors that obtain are quite arcane. Furthermore, the user-space changes required to work around this tend to be rather intrusive. This patch adds an additional `--hipstdpar` specific pass which forwards to the run time component of HIPSTDPAR the intrinsics / libcalls which result from the use of the math builtins, and which are not properly handled. In the long run we will want to stop relying on this and handle things in the compiler, but it is going to be a rather lengthy journey, which makes this medium term escape hatch necessary. The paired change in the run time component is here <ROCm/rocThrust#551>.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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 C++ standard library, as well as generic C++ code, use special compiler builtins to implement math functions. Some of these have non-trivial lowerings and are not handled in the compiler, which leads to rather opaque arcane errors obtaining when compiling code in
--hipstdparmode, wherein they end up directly consumed. This patch adds a header that forwards to the ROCDL implementations via an uniform HIPSTDPAR interface. A corresponding patch in the compiler will handle forwarding the builtins that we cannot directly lower to said uniform HIPSTDPAR interface.With this design, it is possible to provide alternative implementations, and it is also possible for the user to provide their own implementations if e.g. they are compiling with
-nogpuincand / or-nogpulib.