[PATCH] D77954: [CUDA][HIP] Fix overload resolution issue for device host functions

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D77954#1976456 <https://reviews.llvm.org/D77954#1976456>, @yaxunl wrote:

> In D77954#1976378 <https://reviews.llvm.org/D77954#1976378>, @rjmccall wrote:
>
> > I'm not saying that we need to be bug-for-bug-compatible with `nvcc`, I'm just saying that we should be able to point to *something* to justify our behavior.  I take it that the CUDA spec has rules for some amount of host/device-based overloading?  What are they based on?
>
>
> I checked CUDA SDK documentation and did not find useful information about overloading resolution based on host/device attributes. I guess the rule can only be deduced from nvcc behavior.
>
> Based on https://reviews.llvm.org/D12453, https://reviews.llvm.org/D18416, and https://bcain-llvm.readthedocs.io/projects/llvm/en/latest/CompileCudaWithLLVM/#overloading-based-on-host-and-device-attributes, cuda-clang has different overload resolution rules based host/device attributes. This is intentional design decision.


Okay, thanks, that's all I needed.  We don't need to re-litigate it.

That spec says that there's a preference given to functions according to host/device-ness.  The question, then, is how that actually interacts with the normal overload resolution rules.  The "deletion" approach suggests that it's meant to be the most important thing in the comparison.  It seems to me that, given the wording of the specification, deletion is the wrong implementation approach, and that instead this check should just be performed in `isBetterOverloadCandidate` so that a candidate that better matches the host/device-ness of the caller is always considered a better candidate.


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

https://reviews.llvm.org/D77954