[LLVMdev] Casting between address spaces and address space semantics

Eli Friedman eli.friedman at gmail.com
Thu Jul 17 07:25:10 PDT 2008


On Thu, Jul 17, 2008 at 5:08 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote:
> Now, we are using a function which reads a value from one of these memories
> and does some processing. Since we want to execute this function for multiple
> memories, we make it accept a pointer in the generic address space (ie, no
> address space attribute):
>
>        void do_stuff(char* mem);

The "generic address space" you're referring to is really just address
space 0, at least in the current implementation.  Assuming alternate
address spaces are actually separate, passing a pointer from a
different address space to this function is undefined behavior.

> However, this brings me to my actual question: How are address spaces
> semantically defined? I see two options here:
>
> a) Every address space has the full range of addresses and they completely
> live side by side. This means that, for example, i32 addrspace(1) * 100 points
> to a different piece of memory than i32 addrspace(2) * 100. Also, this means
> that a bitcast from one address space to another (possibly 0), makes the
> pointer point to something different when loaded.
>
> b) Every address space is really a subspace of the full range of addresses,
> but always disjoint. This means that, for example, i32 addrspace(1) * 100
> points to the same memory as i32 addrspace(2) * 100, though one, or possibly
> both of them can be invalid (since the pointer lies outside of that address
> space). This also means that bitcasting a pointer from one address space to
> another doesn't change it's meaning, though it can potentially become invalid.

Address spaces are platform-specific, so you can define them any way
you want, I suppose.  But if you can map the alternate address spaces
into address space 0, is there really any point to keeping the other
address spaces around?

-Eli



More information about the llvm-dev mailing list