[cfe-dev] [LLVMdev] Language-specific vs target-specific address spaces (was Re: [PATCH] OpenCL support - update on keywords)

[Peter Collingbourne]

On Thu, Mar 03, 2011 at 04:38:48PM +0000, Peter Collingbourne wrote:
> I generally agree with the concensus reached in the discussion.
> A few points on the implementation:
> 
> 1. The address space mapping should live in CodeGen, specifically
>    in TargetCodeGenInfo.  This is because the physical address space
>    map is a property of LLVM; other intermediate languages may well
>    have their own address space map.  The indication of whether a
>    given target supports OpenCL should still live in TargetInfo as
>    we will need to bail early if the target doesn't have support.
> 
> 3. Clang's LLVM code generator will need to build pointer types
>    frequently, and requiring that a virtual function be called for each
>    pointer type built may slow it down.  Instead, TargetCodeGenInfo
>    should provide a number of lookup tables in the form of arrays,
>    which would be used to define the logical -> physical mapping.
>    Initially we would have 2 lookup tables, one for C/C++/Objective C
>    (which would normally just contain the single entry "0") and the
>    other for OpenCL.
> 
> Also, to avoid regressions in functionality we should retain the
> ability to qualify a pointer with an LLVM physical address space.
> This can be achieved by allocating another bit in the Qualifiers
> class to indicate whether the address space is a logical or physical
> address space.  Physical address spaces would be accessed using the
> existing __attribute__((address_space)) mechanism, while logical
> spaces would be accessed using language-specific keywords.
> 
> I will start working on patches to implement these suggestions,
> based on ARM's 2nd set of patches.

I have completed my patch (attached) based on my suggestions here
and the subsequent discussion.  The main differences with my proposal
here are:

1. I decided to put the address space mapping in TargetInfo after
   all.  This is because we will need to be able to determine
   the size and alignment of pointers in the frontend.

2. I followed John McCall's suggestion and allocated a high
   address space range to be used for the logical address spaces.

3. On IRC John persuaded me that OpenCL __private should always
   map to LLVM address space 0 (address space 0 is defined as the
   address space used for the stack, which is what __private is in
   OpenCL).  So the address space map only has 3 entries (global,
   local, constant), and we do not need a map for C/C++/Objective C.

Thanks,
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcc-keywords.patch
Type: text/x-diff
Size: 33217 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110311/8423e67d/attachment.patch>