[clang] [llvm] [X86] Add Support for X86 TLSDESC Relocations (PR #83136)

[Roland McGrath via cfe-commits]

================
@@ -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
+
+ at x = thread_local global i32 0, align 4
+ at 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