[PATCH] D80858: [CUDA][HIP] Support accessing static device variable in host code for -fno-gpu-rdc

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D80858#2207699 <https://reviews.llvm.org/D80858#2207699>, @tra wrote:

> Sam, just a FYI that the patch has a couple of unintended consequences.
>
> We now end up with various things instantiated as device-side __constant__ objects when they were not before, when we compile with -std=c++17 (especially with libc++):
> https://godbolt.org/z/KbTM9M
>
> That in turn sometimes pulls in other thins that may not exist on the device. E.g. in one case we've ended up with a PTX error caused by unresolved reference to `strlen()` (via some char_traits functions) .
> The other potential issue is that we increase use of `__constant__` and there's only 64K of it, so additional use pushed total use over the limit in few cases.
>
> So far all failures can be attributed to questionable user code, but when we may need to figure out how to avoid emitting unused `__constant__` data.

This is because we have some implicit constant device variables, e.g.

  static _LIBCPP_CONSTEXPR const int __libcpp_polling_count = 64;

then they are referenced by some host functions, e.g.

  template<class _Fn, class _BFn>
  _LIBCPP_AVAILABILITY_SYNC _LIBCPP_INLINE_VISIBILITY
  bool __libcpp_thread_poll_with_backoff(
    _Fn && __f, _BFn && __bf, chrono::nanoseconds __max_elapsed = chrono::nanoseconds::zero())
  {
      auto const __start = chrono::high_resolution_clock::now();
      for(int __count = 0;;) {
        if(__f())
          return true; // _Fn completion means success
        if(__count < __libcpp_polling_count) {
          __count += 1;
          continue;
        }

when `__libcpp_polling_count` has internal linkage, it can be eliminated by optimization pass. When it is externalized, it can no longer be eliminated.

We can restrict externalization to constant variables with explicit 'constant' attributes only, which should fix this issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80858