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

[John McCall 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.

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

John.