yaxunl added a comment. In D86376#2552524 <https://reviews.llvm.org/D86376#2552524>, @tra wrote:
> In D86376#2552419 <https://reviews.llvm.org/D86376#2552419>, @yaxunl wrote: > >> For triple chevron with kernel name, it is not needed. We only need >> indirection for a triple chevron with a function pointer, in which case we >> do not know its stub function at compile time. This is allowed by CUDA/HIP. > > Got it. We'll need to map the address of the symbol into the address of the > stub. > > Adding an indirection brings another question -- what's supposed to happen if > we're passed a pointer that's *not* a pointer to the symbol. I.e. it does not > point to the pointer to the stub. The same thing could happen before this change, i.e., a function pointer does not contain the address of a stub function. In either case it will be UB. This change does not make the situation worse. > Can we backtrack a bit and review our constraints/assumptions. I vaguely > recall AMD inproduced `__device_stub` because debugger needed to distinguish > host-side stub from the device-side kernel. > If we add the data with the same name, would not it cause the same confusion > about what `kernel` is? If we are allowed to use 'kernel' on the host, is > there a reason not to rename `__device_stubkernel` back to `kernel` and just > use the stub address everywhere? We have confirmed with our debugger team that emitting this symbol is OK for rocgdb since it is a variable symbol, not a function symbol. > Another question -- assuming that the stub can't be renamed, can we give the > stub an alias with the name `kernel`? This way no matter how we take the > address, it will always point to the stub. We have tried this and it did not work. The alias will ends up as a symbol to a function which is not allowed by rocgdb. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86376/new/ https://reviews.llvm.org/D86376 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
