[LLVMdev] [PATCH] OpenCL support - update on keywords

[Ken Dyck]

On Thu, Feb 24, 2011 at 1:14 PM, Anton Lokhmotov
<Anton.Lokhmotov at arm.com> wrote:
> Hi Peter,
>
> Many thanks for your prompt review.
>
>> I don't think we should include the word OpenCL in the name of this
>> enum/header.  We may very well in the future want to define address
>> space constants for other languages, which should not overlap with
>> the OpenCL constants, by extending this enum.
> Good point.  We have defined in llvm/Support/AddressSpaces.h:
>
> +namespace llvm {
> +  namespace AddressSpaces {
> +    enum AddressSpace {
> +      PRIVATE = 0,
> +      GLOBAL = 1,
> +      LOCAL = 2,
> +      CONSTANT = 3
> +    };
> +  }
> +}

The address space mechanism is used by some code generators to
differentiate between physical memory spaces. The PIC16 code generator
uses address spaces 0 and 1 to select between its RAM and ROM spaces.
And X86 uses address space 256 for GS and 257 for FS. In the back end
for a dual-harvard DSP that I've been working on, I use address spaces
0-3 to designate the various memories on the machine.

The enum conflicts are easy enough to fix, but this current
implementation doesn't seem to leave room to specify both language-
and target-specific options on the same pointer. For example, when
developing an app for a PIC16, how would a user specify a pointer to a
CONSTANT variable in the ROM space?

Perhaps we could reserve separate bitfields within the address space
number for language- and target-specific options. The OpenCL code
would then need to shift and OR its constants with any address space
numbers specified with the __attribute__ syntax.

-Ken