Strange TLS-related x86_64 pattern (Re: [llvm-commits] [llvm] r107860)

[Ulrich Weigand]

Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
> On Mon, Feb 04, 2013 at 06:17:59PM +0100, Ulrich Weigand wrote:
> > On the other hand, I could not create a test case that actually shows
this
> > problem, because I could never get the above pattern to actually
trigger in
> > the first place.
>
> There is no code lowering to this, I think. For GCC, this would be
> enabled with -mtls-direct-seg-refs.

Well, I do get the effect of what GCC does with -mtls-direct-seg-refs
(i.e. accessing TLS variables via direct offset from the %fs segment).

For example the following IR code:

target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64--linux"

@x = thread_local global i64 0, align 8

define i64 @test() nounwind uwtable {
entry:
  %0 = load i64* @x, align 8
  ret i64 %0
}

compiles down to (with just plain "llc"):

test:                                   # @test
        movq    %fs:x at TPOFF, %rax
        ret

so it *does* access TLS variables by direct offsets from %fs.

It's just that the compiler doesn't use the particular *pattern*
I pointed out in the original mail to do so.  (In fact, I get the
same code when I simply comment out that pattern.)

Bye,
Ulrich