[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 23:47, John McCall wrote:
> 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.

Oh, and now I've found the existing discussion where we've come to the
conclusion that a first-class GAS is acceptable.  Great!

John.