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

[John McCall via cfe-dev]

On 30 Jul 2020, at 15:52, Bader, Alexey wrote:
>> 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).

I believe AMD GPU does also allow the use of explicit address
spaces in their C++ frontend.

Treating the default address space as a superspace of some (all?)
of the other address spaces is sensible and should definitely work.
There are already predicates in the AST for deciding whether two
address spaces are related this way; they probably need to be
target-customizable, but that should be straightforward.

> We have a few IRGen changes to emit "addrspacecast" instead of
> "bitcast" LLVM instruction to keep LLVM IR module consistent.

It’s not unlikely that there are bugs in IRGen, both with the
implicit address space promotion for locals/globals and just
generally with address spaces in C++.  Fixes for those would
be welcome.

John.