Comments (13)
There are some HIP apps or libraries take address of this function. If they hardcode the function type, changing the function signature may break them.
On the other hand, as you said this is in extern "C"
linkage so it is unclear to me how argument types would have anything influence here.
from hip.
they could write code like:
// Define the function pointer
hiprtcResult (*compileProgramPtr)(hiprtcProgram, int, const char**) = nullptr;
// Assign it to point to hiprtcCompileProgram
compileProgramPtr = &hiprtcCompileProgram;
If the signature changes, it breaks (https://godbolt.org/z/fGqKxKbbf)
from hip.
one concern is that this will change the mangled name therefore old HIP apps won't be able to resolve the symbol in the new HIPRTC shared library. One solution might be to keep the old API as an overloaded function that calls the new API.
from hip.
one concern is that this will change the mangled name therefore old HIP apps won't be able to resolve the symbol in the new HIPRTC shared library.
At least in ROCm 5.7 and 6.0, the HIP libraries use C linkage, so there should be no problem with mangled names (but also no way to have an overload):
$ nm -D /opt/rocm-5.7.1/hip/lib/libhiprtc.so | grep hiprtcCompileProgram
0000000000043420 T hiprtcCompileProgram
$ nm -D /opt/rocm-6.0.0/lib/libhiprtc.so.6 | grep hiprtcCompileProgram
000000000000fee0 T hiprtcCompileProgram
from hip.
@yxsamliu Currently, we have a similar task internally to match the signature of hiprtcCreateProgram with nvrtc. i.e, to change the argument types from const char ** to const char* const*. But this was considered breaking backward compatibility and put on hold until 7.0.
@al42and I believe this change will need to wait until next major release ROCm 7.0.
CC @mangupta
from hip.
Okay, that works for us.
Why, though? It is not breaking ABI, and I don't think the API change breaks any backward compatibility in this case.
from hip.
one concern is that this will change the mangled name therefore old HIP apps won't be able to resolve the symbol in the new HIPRTC shared library.
At least in ROCm 5.7 and 6.0, the HIP libraries use C linkage, so there should be no problem with mangled names (but also no way to have an overload):
$ nm -D /opt/rocm-5.7.1/hip/lib/libhiprtc.so | grep hiprtcCompileProgram 0000000000043420 T hiprtcCompileProgram $ nm -D /opt/rocm-6.0.0/lib/libhiprtc.so.6 | grep hiprtcCompileProgram 000000000000fee0 T hiprtcCompileProgram
You are right. This API is actually declared with extern "C" (https://github.com/ROCm/HIP/blob/develop/include/hip/hiprtc.h), therefore it is not mangled.
from hip.
Okay, that works for us.
Why, though? It is not breaking ABI, and I don't think the API change breaks any backward compatibility in this case.
There are some HIP apps or libraries take address of this function. If they hardcode the function type, changing the function signature may break them.
from hip.
If the signature changes, it breaks (godbolt.org/z/fGqKxKbbf)
Yes, but this was not defined in an extern "C" { }
context. So I am confused...
from hip.
Yes, but this was not defined in an extern "C" { } context. So I am confused...
Per my understanding, the problem is not with linkage, but with C++ type system: a pointer to int f(const char**)
is not the same type as a pointer to int f(const char* const*)
. And there is no implicit cast from one type to the other.
And extern "C"
makes things worse. With C++ name mangling, we could have had f(const char**)
and f(const char* const*)
at the same time. But since we need C linking, we can't have both 😿
from hip.
Sure, but in that case it is an API issue, not an ABI issue. Once you ship the new headers with this updated extern "C" { }
declaration, you need to recompile all the stack with the new headers and there will be no missing implicit conversion. Of course all the API users will have to be updated. :-)
But the interesting point, if you have another user using the old API, it will still work because the function with the same name will be linked from the library, even if behind the scene there is an ODR violation and this should be undefined behavior, but this seems under control.
from hip.
And
extern "C"
makes things worse. With C++ name mangling, we could have hadf(const char**)
andf(const char* const*)
at the same time. But since we need C linking, we can't have both 😿
In C++ mode, it would be reasonable to add an API with namespaces like hip::rtc::compiler_program
, but that is another story. ;-)
from hip.
Of course all the API users will have to be updated. :-)
Which means waiting for ROCm 7 (as long as semantic versioning is followed) :(
In C++ mode, it would be reasonable to add an API with namespaces like hip::rtc::compiler_program, but that is another story. ;-)
A story about runtime compilers with a nice C++ API would be interesting indeed.
from hip.
Related Issues (20)
- What are the supported APIs in HIP Graph Management? HOT 4
- [Issue]: Multiple definition error caused by using <hip/hip_bf16.h> HOT 1
- [Issue]: Unable to find header file cmath.h HOT 2
- [Issue]: lld: error: undefined hidden symbol: __ockl_get_group_id, __ockl_get_local_size, __ockl_get_local_id HOT 5
- [Issue]: hipModuleLoad returns error HOT 3
- [Issue]: `__syncthreads` not syncing global memory as per its definition. HOT 7
- [Documentation]: Add information that building on Windows is not supported HOT 1
- [Issue]: Stable diffusion, Pytorch conv2d breaks in rocm 6.0 HOT 4
- Is there any lossless compression available on AMD GPUs in ROCm or HIP? HOT 1
- [Issue]: Unable to install HIP extension for Visual Studio 2022 HOT 8
- [Feature]: Allow specifying maximum size for memory pool HOT 1
- [Issue]: templated __constant__ variables crashes in hipMemcpyToSymbol on ROCm 5.7.1
- support of __float2bfloat162_rn HOT 3
- [Documentation]: examples in "Reference" contain multiple syntax errors HOT 1
- [Issue]: `hipDeviceSetLimit(hipLimitMallocHeapSize, -)` does not behave as specified HOT 2
- [Documentation]: build guide does not handle dependency CppHeaderParser HOT 1
- [Issue]: Windows HIP SDK CMake HIP language support not working HOT 1
- [Issue]: COMGR failed to get code object ISA name HOT 6
- [Issue]: Cannot port with https://rocmdocs.amd.com/projects/HIP/en/latest/user_guide/hip_porting_guide.html
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hip.