[PATCH] D79526: [CUDA][HIP] Workaround for resolving host device function against wrong-sided function
Yaxun Liu via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri May 8 05:19:57 PDT 2020
yaxunl added a comment.
In D79526#2025761 <https://reviews.llvm.org/D79526#2025761>, @tra wrote:
> I've tested the patch on our sources and it still breaks tensorflow compilation, though in a different way:
>
> In file included from third_party/tensorflow/core/kernels/slice_op_gpu.cu.cc:22:
> In file included from ./third_party/tensorflow/core/framework/register_types.h:20:
> In file included from ./third_party/tensorflow/core/framework/numeric_types.h:28:
> In file included from ./third_party/tensorflow/core/platform/types.h:22:
> In file included from ./third_party/tensorflow/core/platform/tstring.h:24:
> In file included from ./third_party/tensorflow/core/platform/cord.h:23:
> In file included from ./third_party/tensorflow/core/platform/google/cord.h:19:
> In file included from ./third_party/absl/strings/cord.h:89:
> ./third_party/absl/strings/internal/cord_internal.h:34:16: error: no matching constructor for initialization of 'std::atomic<int32_t>' (aka 'atomic<int>')
> Refcount() : count_{1} {}
> ^ ~~~
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1778:8: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const std::__u::atomic<int>' for 1st argument
> struct atomic
> ^
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1784:5: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
> atomic() _NOEXCEPT _LIBCPP_DEFAULT
> ^
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1807:52: error: call to deleted constructor of '__atomic_base<base::scheduling::Schedulable *>'
> _LIBCPP_CONSTEXPR atomic(_Tp* __d) _NOEXCEPT : __base(__d) {}
> ^ ~~~
> ./third_party/absl/base/internal/thread_identity.h:162:66: note: in instantiation of member function 'std::__u::atomic<base::scheduling::Schedulable *>::atomic' requested here
> std::atomic<base::scheduling::Schedulable*> bound_schedulable{nullptr};
> ^
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1675:5: note: '__atomic_base' has been explicitly marked deleted here
> __atomic_base(const __atomic_base&) = delete;
> ^
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1786:51: error: call to implicitly-deleted copy constructor of '__atomic_base<long>'
> _LIBCPP_CONSTEXPR atomic(_Tp __d) _NOEXCEPT : __base(__d) {}
> ^ ~~~
> ./third_party/absl/synchronization/mutex.h:927:25: note: in instantiation of member function 'std::__u::atomic<long>::atomic' requested here
> inline Mutex::Mutex() : mu_(0) {
> ^
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1698:7: note: copy constructor of '__atomic_base<long, true>' is implicitly deleted because base class '__atomic_base<long, false>' has a deleted copy constructor
> : public __atomic_base<_Tp, false>
> ^
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1675:5: note: '__atomic_base' has been explicitly marked deleted here
> __atomic_base(const __atomic_base&) = delete;
> ^
>
>
Looks like we went overboard to treat implicit host device candidate as inferior. They should be treated
as inferior in device compilation, not in host compilation. Here because they are treated as inferior
to same-sided candidate in host compilation, they changed overload resolution in host compilation
therefore caused the failure in host compilation.
I have updated the patch to treat implicit host device candidate as inferior in device compilation.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79526/new/
https://reviews.llvm.org/D79526
More information about the cfe-commits
mailing list