[PATCH] D110337: [AMDGPU] Use "amdgpu-hostcalls" attribute to detect if a kernel function hostcall for GPU printf.

Yaxun Liu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 29 20:15:21 PDT 2021


yaxunl added a comment.

In D110337#3018335 <https://reviews.llvm.org/D110337#3018335>, @JonChesterfield wrote:

> Aomp uses the presence of a symbol to determine if the hostcall machinery needs to be initialised. Using the function symbol messes up inlining so it defines a weak (strictly, common to work around an assembler bug) object within the hostcall entry point.
>
>   // The global variable needs_hostcall_buffer is used to detect that
>   // host services are required. If this function is not inlined, the symbol
>   // will not be present and the runtime can avoid initialising said support.
>   __asm__("; hostcall_invoke: record need for hostcall support\n\t"
>           ".type needs_hostcall_buffer, at object\n\t"
>           ".global needs_hostcall_buffer\n\t"
>           ".comm needs_hostcall_buffer,4":::);
>
> I'd suggest hip do the same thing, with a different symbol name to that. It can be detected by looking for that symbol in the code object, same as you do today.
>
> That should be __namespaced, and it would be an abs symbol if the HSA loader understood them, but those limitations notwithstanding it's been working great for ages. Probably over a year since I wrote that.
>
> If the function is inlined, even repeatedly, that asm is still valid. If every call to the function is eliminated, the asm is eliminated and thus the symbol is removed.

We need to check the IR to know whether host call is needed since backend depends on that to determine whether to emit implicit kernel arg runtime metadata. How do we check IR for your approach? Are you suggesting to convey the host call information by symbol instead of runtime metadata? That would be an ABI change.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110337/new/

https://reviews.llvm.org/D110337



More information about the llvm-commits mailing list