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

[Richard Smith via cfe-dev]

On Thu, 6 Dec 2018 at 14:36, Ronan KERYELL via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> >>>>> On Thu, 6 Dec 2018 19:07:30 +0000, "Finkel, Hal J. via cfe-dev" <
> cfe-dev at lists.llvm.org> said:
>
>     Hal> Hi, Andrew, I'd like to fork this part of the thread and move
>     Hal> it to cfe-dev. My best advice is to handle this in Clang, not
>     Hal> LLVM, and I've cc'd Richard and John for their advice. More
>     Hal> 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.
>
>     Hal:
>     >>>>> That seems scary :-) -- Can this inference not be done
>     >>>>> syntactically in Clang?
>
> Actually the generic address space is an OpenCL 2.x feature and does not
> require address space inference since it is expected that the hardware
> will be able to address any kind of address spaces (except the constant
> one, but it is a borderline case). Or it could even be done with run-time
> resolution, probably in a less efficient way.
>
> But of course in some case it might be useful to remove some generic
> address space using some address space inference at compile time and
> replace it by some more concrete address spaces.
>
> An important use case could be to compile OpenCL 2.x programs to run on
> OpenCL 1.x-level hardware, without generic address space support, or
> perhaps because instructions using generic address space are less
> efficient on some OpenCL 2.x hardware, or...
>

Sounds to me like this doesn't require frontend changes, then. (Well,
mostly: if we need to use fat pointers to encode the address space, then
the frontend might need changes to encode that in the data layout and to
increase the size of pointers and such, but that sounds like the extent of
the frontend's responsibilities.) A pass to pick a concrete address space
for a pointer based on usage would belong in the middle-end.


> Is it this the kind of usage Andrew you are working on?
> --
>   Ronan KERYELL
> _______________________________________________
> 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/6271bfc9/attachment.html>