[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 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.

I will start working on patches to implement these suggestions,
based on ARM's 2nd set of patches.

Thanks,
-- 
Peter