[PATCH] D86376: [HIP] Emit kernel symbol

[Yaxun Liu via Phabricator via cfe-commits]

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