Add .stub to kernel stub function name so that it is different from kernel
name in device code. This is necessary to let debugger find correct symbol
for kernel
Details
- Reviewers
t-tye tra rjmccall - Commits
- rGe739ac0e2555: [HIP] change kernel stub name
rC354948: [HIP] change kernel stub name
rL354948: [HIP] change kernel stub name
rG00ebc0cb92e9: revert r354615: [HIP] change kernel stub name
rL354651: revert r354615: [HIP] change kernel stub name
rC354651: revert r354615: [HIP] change kernel stub name
rG8d7cf0e2d4b5: [HIP] change kernel stub name
rL354615: [HIP] change kernel stub name
rC354615: [HIP] change kernel stub name
Diff Detail
- Repository
- rL LLVM
Event Timeline
My guess is that this is needed because HIP debugger can see symbols from both host and device executables at the same time. Is that so?
If that's the case, I guess HIP may have similar naming problem for __host__ __device__ foo() if it's used on both host and device.
lib/CodeGen/CGCUDANV.cpp | ||
---|---|---|
230–231 ↗ | (On Diff #187815) | It may be worth adding a comment why kernel stub in HIP needs a different name. |
Probably, will fix it in seperate patch if it is true.
lib/CodeGen/CGCUDANV.cpp | ||
---|---|---|
230–231 ↗ | (On Diff #187815) | will do when commit |
Yes this relates to supporting the debugger.
For the same function being present on both host and device, having the same name is correct as the debugger must set a breakpoint at both places. This is similar to needing to set a breakpoint at every place a function is inlined.
I'm confused. Are you saying that HIP does *not* need a different name for the stub then?
To clarify, I am saying that the stub does have a different name since it is conceptually part of the implementation of doing the call to the device function implementation, and is not in fact the the device function being called itself. However, when we generate code for a function that is present on both the host and device, both copies of the code are for the same source level function and so can have the same symbol name (which was a question that was asked).
lib/CodeGen/CodeGenModule.cpp | ||
---|---|---|
1059 ↗ | (On Diff #187980) | Changing mangled name exposes this change to a wider scope of potential issues. Is the mangled name still valid after this change? I.e. will external demanglers have problem with it? Is . a valid symbol in mangled names on all platforms we support? I think changing the name here is way too late and we should figure out how to change the stub name when we generate it. @echristo Eric, what do you think? |
lib/CodeGen/CodeGenModule.cpp | ||
---|---|---|
1059 ↗ | (On Diff #187980) | The external demangler can still demangle this name. e.g. c++filt will demangle this name and add [clone .stub] after that. As far as I can see this function is only called in codegen to map FunctionDecl names to LLVM function names. I've tried this change with real ML frameworks and it works. Changing at this place is not too late. The stub function name is requested at multiple places in codegen, not just at the emitting of stub function definition. For template kernel function, the emitting of stub function definition is deferred after emitting of the call of the stub function. Basically, codegen needs to find the corresponding LLVM stub function by getMangledName first, then by GetOrCreateLLVMFunction. If we do not change getMangledName, codegen will not get the correct stub function name consistently at all places. That's why the previous patch does not work. |