[llvm-dev] when would I use addrspacecast?
Hayden Livingston via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 6 09:12:22 PDT 2015
Thanks. Seems like a case where a hardware provider makes such things
available. My development is Windows and Linux on x86 and ARM, don't
think I'll be seeing this.
On Tue, Oct 6, 2015 at 2:26 AM, mats petersson <mats at planetcatfish.com> wrote:
> 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 off].
> 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).
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
More information about the llvm-dev