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

[Ken Dyck]

On Wed, Mar 2, 2011 at 6:14 PM, David Neto <dneto.llvm at gmail.com> wrote:
> I disagree with Speziale.   OpenCL address spaces are not "scopes"
> or scope-like things.  OpenCL address spaces describe disjoint storage
> locations with incompatible pointer types, and with independent address
> numbering (i.e. if you happened to cast a pointer to an integer).
>
> For example, Clang makes sure that you can't assign a pointer to one
> address space into a pointer to another address space.
> "illegal implicit conversion between two pointers with different
> address spaces".
> OpenCL has that restriction as well: Section 6.8 paragraph a.
>
> So I argue you really do want to use Clang address spaces to represent
> OpenCL address spaces.

Okay. You've convinced me.

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

-Ken