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

[Richard Smith via cfe-dev]

Hi Andrew,

Can you please provide a reference to the relevant part of the OpenCL
specification describing this feature? This sounds like an extremely
surprising and problematic language design choice, and I'd like to make
sure we're not misinterpreting the specification.

(Some specific things that are unclear here: Where can GAS pointers be
used? Can I put them in a struct? Can I make an array of them? Are all
array elements required to point to the same address space? Are they
mutable? Can I assign pointers from multiple different address spaces to
the same GAS pointer? Must functions taking GAS pointers be defined in the
same translation unit as the call? Can different GAS parameters resolve to
different address spaces? Can you take the address of a function taking GAS
pointers?)

On Thu, 6 Dec 2018 at 11:07, Finkel, Hal J. via cfe-dev <
cfe-dev at lists.llvm.org> 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.
>
>  -Hal
>
> >
> >> We can change the order that functions are emitted in Clang if
> necessary.
> >>
> > I haven't thought this is actually configurable. I'd really appreciate
> > if you can give me a pointer on how to do this.
> >
> >
> >
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181206/a04a0dde/attachment.html>