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

[Andrew Savonichev via cfe-dev]

Ronan KERYELL writes:
>>>>>> 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...
>
> Is it this the kind of usage Andrew you are working on?

You're right, my definition of GAS was too strict - OpenCL specification
does allow dynamic GAS resolution, but it requires backend (or hardware)
support to do that.

For static GAS resolution my use cases are:
1) backends (e.g. based on OpenCL 1.x) which do not support GAS natively.
2) performance and code size improvements that can be archived by GAS
   static resolution.

For (2) I'm probably fine with running this analysis after
optimizations, but support for debug (no-opt) can be important for (1).

-- 
Andrew

--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.