TLS and x86-64 fs:

IGotD- nise at nise.com
Thu Jun 29 09:10:03 UTC 2023


On Wednesday, 28 June 2023 at 23:39:43 UTC, Cecil Ward wrote:
> It seems that in x86-64 Linux (which I think is what 
> godbolt.org uses - is that correct?), LDC emits a function call 
> to get the address of your TLS static base. GDC seems to be 
> vastly more efficient as it simply uses an fs: segment override 
> and apart from that accesses the RAM directly. I don’t know 
> what is happening if someone takes the address of a TLS static 
> and mixes it with a comparison or pointer arithmetic with say 
> an alloc cell or address in one of the stacks. How that works 
> is a GDC question.
>
> I wonder why the difference in method between the compilers ? 
> Could LDC steal the GDC tech here in order to get much more 
> speed ?

LDC doesn't need to steal anything because TLS access is a 
standard, for Linux in the ELF and runtime ABI for the CPU 
architecture standard. The difference is because they are several 
different ways accessing TLS. Typically, if you access TLS from 
the main executable, then the compiler can optimize TLS accesses 
using the fs segment on x86. I don't know why LDC chooses to use 
a function call but this is likely to be a setting in LLVM as it 
should support all types of accesses.

Function calls to obtain TLS access is typically used when the 
code is in a dynamically loaded library that was loaded by your 
code (not "statically" loaded library that the linker can 
determine at link time, I know it's a bit messy to understand 
this).

A system standard (operating system) can actually choose what 
types of TLS access is supposed to be used.



More information about the digitalmars-d-ldc mailing list