[cfe-dev] [RFC] Re-use OpenCL address space attributes for SYCL

[David Rector via cfe-dev]

On Jul 27, 2020, at 12:18 PM, Bader, Alexey via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> > I don't think (2) deal with language semantics. I assume we both talking about
> > the same case when variable declaration is not explicitly annotated with address
> > space attribute. According to language semantics such objects are allocated in
> > generic address space, but the problem is that most OpenCL implementations have
> > problems with consuming SPIR-V files with global variables in generic address
> > space. As an alternative to CodeGen changes we can consider handling this issue
> > in SPIR-V translator tool.
> 
> 
> I am not really a CodeGen expert, maybe it will be ok. I think it's better if you discuss
> it with John McCall or someone who is more experienced with CodeGen architecture.
> 
> Why don't you just do regular address space deduction in Sema and then cast the
> deduced address space to generic straight after? You already add similar casts for
> pointers that are annotated with address spaces through the user code, right?
> This approach will probably allow to reuse the logic from OpenCL and simplify CodeGen.
 
I don't see how it can be done without breaking C++ semantics demonstrated in
https://reviews.llvm.org/D80932#2073542 <https://reviews.llvm.org/D80932#2073542>. 

I am not well-versed in this, but just thinking about these as arbitrary type qualifiers: could the issue be simply that the implicitly-generated address space qualifiers are *only* being added to the types of VarDecls, rather than to *every* type, including pointee types, template argument types, etc.?

I.e., referring to the examples linked to above: perhaps the problem is *not* that that OpenCL changes `int var` to `__private int var`, but rather that it does not *also* change `int* ptr1 = &var` to `__private int* __private ptr1 = &var` (or whatever the proper default qualifiers are) and `std::is_same<T, int>` to `std::is_same<T, __private int>` when in OpenCL (or SYCL) mode.

If it did, I believe those examples would all compile, and code would only break when the user specified began specifying non-default address spaces, i.e. when they actually used the feature in their code.  In this way, the non-standard semantics could be represented in the AST without affecting the standard semantics.

In any case that is the form of the ideal solution: sure, don’t break the standard C++ semantics, but also, try to keep a clear representation of any supported-but-non-standard semantics in the AST, I think.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200727/2802d76a/attachment.html>