tra added a comment. 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. 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? 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. 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
