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

[John McCall]

On Mar 3, 2011, at 8:38 AM, Peter Collingbourne wrote:

> On Thu, Mar 03, 2011 at 09:02:24AM -0500, Ken Dyck wrote:
>>>> In my opinion, any knowledge that front ends have of address spaces
>>>> should be dictated by the target's back end. Perhaps we should add
>>>> some virtual methods to LLVM's TargetMachine interface so front ends
>>>> can query the back end for the names and numbers of the address spaces
>>>> that they recognize, and expose them to end users in a standard way.
>>>> But having front ends impose the requirement on back ends that they
>>>> recognize some arbitrary set of language-specific address spaces seems
>>>> like a great misuse of the feature to me for reasons that Peter has
>>>> already pointed out.
>>> 
>>> This makes sense to me.   So the TargetMachine would advertise what
>>> address spaces it has, and how they map to OpenCL address spaces (if at all).
>>> Then Clang could error out gracefully if the user is compiling OpenCL code and
>>> the target doesn't support OpenCL.  That addresses the basic validity issue.
>> 
>> On second thought, Clang's TargetInfo class would probably be a better
>> location for this logic, since the TargetMachine object isn't
>> instantiated until back-end code generation, which is too late to be
>> useful for IR generation.
>> 
>> Roughly, I'm proposing the following additions to TargetInfo.h:
>> 
>> + enum OpenCLAddressSpace {
>> +   OPENCL_PRIVATE,
>> +   OPENCL_GLOBAL,
>> +   OPENCL_LOCAL,
>> +   OPENCL_CONSTANT
>> + };
>> 
>> ...
>>  class TargetInfo {
>> ...
>> 
>> + /// hasOpenCLAddressSpaces - returns true if the target supports a
>> mapping of the OpenCL address
>> + /// spaces (private, global, local, and constant) to address space
>> numbers via getAddressSpace().
>> + virtual bool hasOpenCLAddressSpaces() const { return false; }
>> +
>> + /// getAddressSpace - returns the target-specific address space
>> number corresponding to the given
>> + /// OpenCL address space qualifier.
>> + virtual unsigned getAddressSpace(OpenCLAddressSpace qualifier) { return 0; }
>> 
>> Obviously, hasOpenCLAddressSpaces() and getAddressSpace() would need
>> to be overridden for the targets that can support OpenCL.
> 
> 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.

If "logical" and "physical" address spaces are exclusive, you can
support this by simply recognizing certain address space numbers
as special.  There's no need to complicate Qualifiers here.

John.