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>

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>

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>.

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>.

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>.