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

[Anastasia Stulova via cfe-dev]

> 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.?

It is a little bit more complex than that. Most of the types used with objects in OpenCL will get an address space deduced including pointer types. This is because OpenCL is a language dialect for memory segmented architectures and the memory segments pose some limitations resulting in extra language rules. Clang strictly follows OpenCL language spec and  I don't see any issue in the examples Alexey has referred to. If the types differ by address space is_same is expected to return false.
What I struggle to understand how does this affects SYCL at all? The deduction of address spaces is guarded by OpenCL language mode and it is not set for SYCL as far as I am aware.

> 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

If I understand the design Alexey is proposing correctly the user-specified address spaces are cast to the default address spaces "hiddenly" and the AST always ends up to be in flat address space. This is why I don't see the address space as a good fit. However, I am not sure this is explained explicitly in the RFC, I might have remembered this from some other discussions.

________________________________
From: David Rector <davrecthreads at gmail.com>
Sent: 27 July 2020 22:32
To: Bader, Alexey <alexey.bader at intel.com>
Cc: Anastasia Stulova <Anastasia.Stulova at arm.com>; cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>; rjmccall at apple.com <rjmccall at apple.com>; nd <nd at arm.com>
Subject: Re: [cfe-dev] [RFC] Re-use OpenCL address space attributes for SYCL

On Jul 27, 2020, at 12:18 PM, Bader, Alexey via cfe-dev <cfe-dev at lists.llvm.org<mailto: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.

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/20200729/53f2277c/attachment.html>