Improve ELF TLS detection on OSX

[alexcrichton]

Currently a compiler can be built with the --disable-elf-tls option for compatibility with OSX 10.6 which doesn't have ELF TLS. This is unfortunate, however, as a whole new compiler must be generated which can take some time. These commits add a new (feature gated) cfg(target_thread_local) annotation set by the compiler which indicates whether #[thread_local] is available for use. The compiler now interprets MACOSX_DEPLOYMENT_TARGET (a standard environment variable) to set this flag on OSX. With this we may want to start compiling our OSX nightlies with MACOSX_DEPLOYMENT_TARGET set to 10.6 which would allow the compiler out-of-the-box to generate 10.6-compatible binaries.

For now the compiler still by default targets OSX 10.7 by allowing ELF TLS by default (e.g. if MACOSX_DEPLOYMENT_TARGET isn't set).

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

cc @brson, @rillian

This is primarily motivated by Gecko which requires 10.6 compatibility but is currently having to compile their own OSX toolchain (with --disable-elf-tls). The primary benefit for this to them is if we ourselves start compiling our nightlies to run on 10.6, which means the standard library won't use ELF TLS. External consumers of the standard library, however, will continue to use ELF TLS by default. This seems like an ok balance between compatibility and speed to me, but I'm curious what others think!

[rillian]

Thanks, @alexcrichton! For gecko we actually build on 10.7, so the compiler itself can use ELF TLS, we just need it to be able to produce binaries which work on 10.6 (and so libstd must not use ELF TLS) when MACOSX_DEPLOYMENT_TARGET is < 10.7.

If I understand the patch properly, that case is still covered by building nightlies with MACOSX_DEPLOYMENT_TARGET=10.6, but I wanted to be sure the requirement is clear.

[alexcrichton]

Ah yeah thanks for clarifying, right now the build which produces standard libraries for OSX also produces compilers, so for us they're one and the same. I could imagine, however, that we start providing alternate compilation profiles of the standard library and this could certainly be one of them!

[bors]

☔ The latest upstream changes (presumably #30457) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #30184) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Ah and I finally got around to doing some benchmarking, and of this simple benchmark:

#![feature(test)]
#![feature(static_mutex, const_fn)]

extern crate test;

use std::sync::StaticMutex;

pub fn doit() {
    static L: StaticMutex = StaticMutex::new();
    drop(L.lock());
}

#[bench]
fn bench_a(bh: &mut test::Bencher) {
    bh.iter(|| { doit() });
}

The timings look like:

$ ./use-elf-tls --bench

running 1 test
test bench_a ... bench:          22 ns/iter (+/- 13)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured

$ ./use-os-tls --bench

running 1 test
test bench_a ... bench:          24 ns/iter (+/- 9)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured

So we may actually be able to turn on 10.6 support by default in nightlies with little-to-no performance impact

[alexcrichton]

Ah and a similar benchmark for just raw TLS access times:

#![feature(test)]
#![feature(const_fn)]

extern crate test;

use std::cell::Cell;

#[bench]
fn bench_a(bh: &mut test::Bencher) {
    thread_local!(static C: Cell<usize> = Cell::new(0));
    bh.iter(|| {
        C.with(|c| {
            let r = c.get();
            c.set(r + 1);
            r
        })
    })
}

Shows a difference of 4ns/iter vs 5ns/iter for ELF vs OS tls (respectively), so it may actually be that libstd is barely affected at all in terms of perf.

[aturon]

I'm 👍 on this change, and likely for changing the default target in our release artifacts as well.

[brson]

@bors r+

[bors]

📌 Commit c211a78 has been approved by brson

[bors]

⌛ Testing commit c211a78 with merge b2b8f4e...

[bors]

💔 Test failed - auto-linux-64-x-android-t

[alexcrichton]

@bors: r=brson 617a7af

[bors]

🙀 617a7af is not a valid commit SHA. Please try again with cd74364.

[alexcrichton]

@bors: r+ cd74364

[bors]

⌛ Testing commit cd74364 with merge 42c3ef8...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt