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

[Bader, Alexey via cfe-dev]

> On 27 Jul 2020, at 17:32, David Rector wrote:
> > 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.
> 
> I haven’t been paying close attention to this thread, so I’m not sure exactly
> what’s being asked here, and I couldn’t figure it out from the original post.  If
> you have specific questiions, I’d be happy to help.
> 
> It does sound like it would be useful for me to point out that IRGen already
> has the ability to emit local and global variables in an address space that
> doesn’t match the formal address space of a declaration’s type.  This was
> added for the AMD GPU target so that it could support arbitrary C++ code.
> IRGen just has some target hooks that you can override to set the default
> address spaces for these kinds of variables.
> 
> To give you an idea of how this is used, for AMD GPU, IRGen emits
> local/global declarations using the target’s private and global address spaces,
> but it translates pointers and references to use the generic address space.
> When IRGen emits a reference to one of these variables, therefore, it has to
> immediately promote the pointer to the variable into the generic address
> space, and all the subsequent operations work on that generic pointer.  Like
> most GPU targets, AMD GPU then has extensive optimizations to try to
> strength-reduce operations on generic pointers down to operations on
> specific address spaces.

We applied similar approach for SPIR target. In addition to arbitrary C++ code,
we need to allow users explicitly set address space. We are trying to achieve
this by supporting address space attributes in SYCL mode, which can be casted to
"default" address space (including implicit casts). We have a few IRGen changes
to emit "addrspacecast" instead of "bitcast" LLVM instruction to keep LLVM IR
module consistent.

> That’s probably the cleanest alternative if you don’t want to take the OpenCL
> route of inferring specific address spaces based on other characteristics of
> the declaration.  Any approach that exposes address spaces in the source
> language can certainly lead to rejecting code which would be valid in standard
> C++.

We arrived at the same conclusion as well while we were trying to re-use OpenCL
mode for SYCL.