[PATCH] D78655: [HIP] Let lambda be host device by default

[Artem Belevich via Phabricator via cfe-commits]

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