Details

Emulated TLS is enabled by llc flag -emulated-tls, which is passed by clang driver.
When llc is called explicitly or from other drivers like LTO, missing -emulated-tls flag would generate wrong TLS code for targets that supports only this mode.
Now use useEmulatedTLS() instead of Options.EmulatedTLS to decide whether emulated TLS code should be generated.
Unit tests are modified to run with and without the -emulated-tls flag.

First the easy things:
The llc tool is not intended to be a user-facing tool, so I don't think that justifies it on its own.
This breaks -fno-emulated-tls.

Then, LTO...
For sure, the way that flags get passed down into LTO currently is certainly a quite-irritating set of kludges. However, teaching the clang driver to pass the right flag through to the lto plugin seems entirely possible, and would seem to actually fix the issue more completely, also handling a user-specified -femulated-tls flag on non-android platforms.

I don't think -fno-emulated-tls is used anywhere yet.
I should have not allowed that flag.
My original idea was to have only -femulated-tls for
targets like Android.

Anyway I don't want to disable -fno-emulated-tls now.
So the new patch has added ExplicitEmulatedTLS to
indicate that either -emulated-tls or -no-emulated-tls
is passed to code generator.
If ExplicitEmulatedTLS is not set, like current LTO,
we should use the target triple to decide EmulatedTLS.

I don't trust all front-end drivers to set -emulated-tls correctly.
There will be more tools to call llc.
We should have correct target dependent default for code generator.