[PATCH] D62584: [OpenCL][PR42033] Deducing addr space with template parameter types

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia marked an inline comment as done.
Anastasia added inline comments.


================
Comment at: lib/Sema/TreeTransform.h:5363
+    if (ResultType.getAddressSpace() != LangAS::Default &&
+        (ResultType.getAddressSpace() != LangAS::opencl_private)) {
       SemaRef.Diag(TL.getReturnLoc().getBeginLoc(),
----------------
rjmccall wrote:
> Anastasia wrote:
> > I am trying to be a bit more helpful here although I am not sure if we should instead require explicit template parameter and fail the template deduction instead.
> > 
> > Basically, do we want the following code to always require specifying template argument explicitly:
> > 
> > 
> > ```
> > template <class T>
> > T xxx(T *in) {
> >   T *i = in;
> >   return *i;
> > }
> > 
> > __kernel void test() {
> >   int foo[10];
> >   xxx<int>(&foo[0]); // if we deduce type from foo, it ends up being qualified by __private that we currently diagnose. However private is default (implicit) address space for return type so technically there is no danger in just allowing xxx(&foo[0])
> > }
> > ```
> Implicitly ignoring all address-space qualifiers on the return type seems like the right thing to do; I don't think it needs to be limited to `__private`.  That's probably also the right thing to do for locals, but I'm less certain about it.
Just to clarify by "Implicitly ignoring" you mean ignoring if the templ parameters were deduced?

Although I am a bit concerned about allowing other than `__private` address spaces in return types as we reject them in return types of functions generally. Would it not be somehow inconsistent?


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

https://reviews.llvm.org/D62584