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

[Ronan KERYELL via cfe-dev]

>>>>> 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?
-- 
  Ronan KERYELL