[LLVMdev] ideas for TLS implementation
Lauro Ramos Venancio
lauro.venancio at gmail.com
Wed Apr 11 11:15:36 PDT 2007
For everyone understand which code must be emitted to implement TLS, I
will paste the code generated by gcc for a simple function:
__thread int a = 1;
int f(){
return a;
}
gcc teste.c -o teste.s -S -O2 (arm-linux-gnueabi):
.global a
.section .tdata,"awT",%progbits <== special section for
tls symbols
.align 2
.type a, %object
.size a, 4
a:
.word 1
.text
.align 2
.global f
.type f, %function
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
str lr, [sp, #-4]!
ldr r3, .L2
bl __aeabi_read_tp @ load_tp_soft <== get thread pointer
(abi dependent)
ldr r0, [r0, r3]
ldr pc, [sp], #4
.L3:
.align 2
.L2:
.word a(tpoff) <== offset of "a"
.size f, .-f
The idea of implementing TLS is to create the "thread_local" keyword.
The program above would be converted to this:
@a = thread_local global i32 1 ; <i32*> [#uses=1] <== Thread
local keyword
define i32 @f() {
entry:
%tmp1 = load i32* @a ; <i32> [#uses=1]
ret i32 %tmp1
}
With "thread_local" keyword, the backends can emit TLS code. The TLS
is architecture and abi dependent, so I think we must let the backends
handle with TLS symbols. Each backend must handle each TLS model.
> Adding TLS support seems to be tricky, since there are 4
> different TLS "models" with different "assumptions".
There is a model ("general dynamic") that works in all situations. The
other three models are optimizations of the first. So, I think we
should start implementing the "general dynamic" model.
I believe the roadmap is:
1. make LLVM understand "thread_local" keyword. (AsmParser, AsmWriter,
BCReader, BCWriter)
2. make llvm-gcc emit "thread_local" keyword
3. implement "thread_local" in C backend (model independent)
3. implement "general dynamic" tls model for i386-linux-gnu
4. implement "general dynamic" tls model for arm-linux-gnueabi (this
is more complex because gcc 4.0 doesn't support tls for arm. I will
have to backport a patch from gcc 4.1 to llvm-gcc)
5. Maybe implement other models for arm-linux-gnueabi
Suggestions are appreciated. :-)
Lauro
More information about the llvm-dev
mailing list