tra added a comment.

In D78655#2013226 <https://reviews.llvm.org/D78655#2013226>, @pfultz2 wrote:

> > Not only the capture is an issue, like a regular function, lambda could 
> > also access non-local variables/functions.
>
> In practice this is not an issue. Hcc will implictly treat anything inlinable 
> as host device, and user's are not confused or surprised when they use 
> non-local variables/reference that are on the host.
>
> > From the other perspective, a lambda is just another function and should 
> > have consistent rule for its usage, resolution, and etc.
>
> But its not like another function.


+1. Lambda is an object. In addition to operator(), it may also have local 
storage for captured variables and can also be mutable, which makes it even 
more complicated. I.e. if I pass a mutable lambda by reference to the GPU 
kernel, will the same lambda called on host do the same thing when it's called 
on the device? In principle it would work if GPU and host operate un a uniform 
memory (i.e. all memory is accessible at the same addresses from both host and 
the GPU), but I don't think it's a universally true assumption. E.g. GPU-to-GPU 
memory accesses are not always possible, even when they technically share the 
same address space with the host. I can create a capturing lambda on one GPU, 
pass it to the host (may work fine there), pass it to another GPU and it will 
fail.

> Lambdas are also implicitly `constexpr` whereas a function need to explicitly 
> declare `constexpr`.

According to cppreference, it's only true since C++17 and, AFAICT, only for 
capture-less lambdas.

> Making lambdas implicitly HD whereas function need to be explicit seems to be 
> consistent with how lambdas work with `constexpr`.

Considering they are not always constexpr, this assertion is not true, either.

If/when `operator()` does get constexpr treatment by compiler, we should 
already derive HD attributes from `constexpr`. If we do not, then that's what 
needs to be fixed. That at least would make sense from consistency standpoint 
as we currently do treat all other constexpr functions as HD.


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

https://reviews.llvm.org/D78655



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to