[cfe-dev] OpenCL Generic Address Spaces - CodeGen (was Re: [llvm-dev] AliasAnalysis does not look though a memcpy)

[John McCall via cfe-dev]

On 6 Dec 2018, at 14:07, Finkel, Hal J. wrote:
> Hi, Andrew,
>
> I'd like to fork this part of the thread and move it to cfe-dev. My 
> best
> advice is to handle this in Clang, not LLVM, and I've cc'd Richard and
> John for their advice. More inline...
>
> On 12/6/18 10:46 AM, Andrew Savonichev wrote:
>> ...
>>>>>>> Can you say more about the use case?
>>>>>> OpenCL C has a notion of Generic Address Space (GAS), allowing 
>>>>>> you to
>>>>>> cast a pointer from any (named) address space to a GAS pointer. 
>>>>>> Then you
>>>>>> can use this GAS pointer instead of a named AS pointer. Compiler 
>>>>>> is
>>>>>> responsible to infer the original address space of a GAS pointer 
>>>>>> when it
>>>>>> is actually used (for load/store), otherwise this is a 
>>>>>> compilation
>>>>>> error.
>>>>> That seems scary :-) -- Can this inference not be done 
>>>>> syntactically in
>>>>> Clang?
>>>>>
>>>> From a frontend perspective, a GAS pointer is just a pointer:
>>>>
>>>>   void foo(int *p, int *q) { *p = 42; *q = 43; };
>>>>
>>>> Until Clang reaches a call site, it has no idea about real address
>>>> spaces of `p' and `q'. When we do reach a call site, `foo()' can 
>>>> already
>>>> be CodeGen'ed, so we can't really change anything.
>>> Is this supposed to work like template instantiation? Are you 
>>> guaranteed
>>> to only get one (unique) set of address spaces for the function
>>> arguments?
>>>
>> Yes, just like in C++ template, if `foo' is called with different 
>> sets
>> of address spaces, a compiler have to create different function
>> instantiations for each set.
>
> I think that you should handle this in Clang using TreeTransform, in a
> sense, just like C++ template instantiation. See
> lib/Sema/TreeTransform.h, and there are a number of examples in 
> lib/Sema
> of transforms using this infrastructure. Using TreeTransform you would
> create variants of each function with the right address spaces, based 
> on
> usage, and then emit them all during CodeGen. because you'd do this
> prior to code generation, you don't need to worry about the emission
> ordering.

I think it depends a lot on the language rules.  If the language rules
are set up so that we can easily propagate qualifiers from the arguments
without a complex analysis, well, okay, TreeTransform makes sense.  But 
I
think it's much more likely that this would have to be a 
data-flow-sensitive,
best-effort analysis that simply fails in arbitrary ways if the 
optimizer
isn't able to fully eliminate a use of the generic address space.

To enable a TreeTransform-based implementation, we'd have to be able to 
infer
a concrete address space immediately for every place where the GAS would
otherwise be used in the function, and when those places are e.g. the 
types
of local variables, that inference must prove to be consistent with 
other uses
of the variable/whatever as we propagate type information forward.

I don't really know how that inference would work; it sounds incredibly
complicated.  But then, admittedly, so does a data-flow-sensitive 
rewrite.

John.