[llvm-dev] when would I use addrspacecast?

mats petersson via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 6 02:26:49 PDT 2015

Some languages, such as OpenCL, has address spaces that are not part of
standard C. This may mean "add some offset to the pointer [if it's not
NULL]" (the offset may be in a hardware register and depend on the current
thread or some such too).

I expect one could use this in C to support Thread Local Storage, for
example. I don't know if Clang actually does that, or has some separate
mechanism for solving this. In x86, the TLS is supported by using the
segment register to hold the base-address into the TLS memory for a given
thread, so a addrspacecast to "global" address space would then be a LEA
RDX, FS:[RAX] to convert from offset RAX in TLS into a global pointer in
RDX [it's a few years since I worked on x86-64 assembler, so syntax may be


On 6 October 2015 at 09:31, David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 6 Oct 2015, at 06:39, Hayden Livingston via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I was reading the LangRef for semantics of an instruction and came
> > across addrspacecast. I've never needed it, so I suppose I don't care
> > about it.
> You use it when you have a pointer in one address space and you wish to
> have a pointer in another address space.
> > But, why does it exist? What problem is it trying to solve?
> Casts between address spaces may not be simple bitcasts.  For example, you
> may have one address space that uses 32-bit integers to cover all of
> physical memory and 16-bit pointers in some fast scratchpad memory.  It may
> or may not be defined to cast a 16-bit pointer to a 32-bit one (it
> definitely won’t be a simple sign / zero extension, but it may be a masking
> operation if the fast memory is mapped into the larger address space).
> David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151006/4022a4ed/attachment.html>

More information about the llvm-dev mailing list