================
@@ -0,0 +1,165 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 4
+; RUN: llc < %s -mtriple=i686-unknown-unknown --relocation-model=pic
-enable-tlsdesc | FileCheck %s --check-prefix=X86
+; RUN: llc < %s -mtriple=x86_64-pc-linux-gnux32 --relocation-model=pic
-enable-tlsdesc | FileCheck %s --check-prefix=X32
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown --relocation-model=pic
-enable-tlsdesc | FileCheck %s --check-prefix=X64
+
+@x = thread_local global i32 0, align 4
+@y = internal thread_local global i32 0, align 4
----------------
frobtech wrote:
I think it's worthwhile to have test cases that are `dso_local` but not
internal linkage as well, and mixing the two. These can and should also use
`_TLS_MODULE_BASE_` with the secondary `dtpoff` offset after the TLSDESC call
returns. e.g.
```
extern __thread int x __attribute__((visibility("hidden")));
static __thread int y;
int foo() { return ++x + ++y; }
```
The ideal thing is probably *not* to use `_TLS_MODULE_BASE_` when its result is
used only once in the function, regardless of the linkage details of the
referenced TLS symbol. That's because a second addition with the `dtpoff`
value will always be needed for that. If it's a case where that addition is
"free", e.g. because it can be rolled into the displacement of a load you're
doing anyway, then using `_TLS_MODULE_BASE_` is ideal even if it's the only use
in the function (because the GOT slot & relocs will be shared with any other
such use in the whole link). However, if it requires an extra instruction to
do the add after the TLSDESC call returns, then it's probably better overall to
have the separate reloc for just that access.
https://github.com/llvm/llvm-project/pull/83136
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
