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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
