[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

Yaxun Liu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 8 13:52:37 PST 2019


yaxunl added a comment.

In D56411#1349364 <https://reviews.llvm.org/D56411#1349364>, @jlebar wrote:

> Without reading the patch in detail (sorry) but looking mainly at the testcase: It looks like we're not checking how overloading and `__host__ __device__` functions play into this.  Maybe there are some additional edge-cases to explore/check.


will add test for `__host__` `__device__`.

> Just some examples:
> 
> Will we DTRT and parse `bar` call as calling the `device` overload of `bar` in
> 
>   __host__ void bar() {}
>   __device__ int bar() { return 0; }
>   __host__ __device__ void foo() { int x = bar(); }
>   template <void (*devF)()> __global__ void kernel() { devF();}
>   
>   kernel<foo>();
> 
> 
> ?  Also will we know that we don't have to codegen `foo` for host (so `foo` is actually able to do things that only device functions can)?

we DTRT for this case. Here `__host__` bar needs to return int since foo() expects that. will add a test for that.

> Another one: How should the following template be instantiated?
> 
>   __host__ constexpr int n() { return 0; }
>   __device__ constexpr int n() { return 1; }
>   template <int> __global__ void kernel() {}
>   
>   kernel<n()>
> 
> 
> Presumably the call to `n` should be the host one?  That seems correct to me, but then it's pretty odd that a function pointer template argument would point to a *device* function.  Maybe that's the right thing, but I bet I can come up with something weird, like:

I think n() should be resolved in the containing function context. n itself is not template argument. the result of n() is.

> 
> 
>   __host__ void bar() {}
>   __device__ int bar() { return 0; }
>   __device__ auto baz() -> decltype(foo<n()>()) {} // which n() does it call?  Presumably host, but:
>   __device__ auto baz() -> decltype(bar()) {}  // does baz return void or int?  Presumably...the device one, int?
> 
> 
> Now mix in templates and sizeof and...yeah.  Rife for opportunities.  :)

I think this example is different from the issue which this patch tries to address. In the case of function type template parameter, it is less controversial about host/device resolution. The function argument is supposed to be called by the function template, therefore its host/device attribute should be consistent with the function template. Whereas in the above decltype example, such reqirement does not exist. Therefore I tend to suggest we keep things as they are, i.e., bar is host/device resolved in its containing function context.


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

https://reviews.llvm.org/D56411





More information about the cfe-commits mailing list