[llvm-dev] [cfe-dev] lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

[Gaetano Checinski via llvm-dev]

> Unfortunately it doesn't look like lli has support for emulated TLS either,
though that would be pretty simple to add.
As an experiment I've `llvm::createLowerEmuTLSPass` into lli which
added @__emutls_v.x and @__emutls_v.t.
However i didn't have any __emultls_get_address calls in my IR.
Is there a llvm pass or compiler-flag that replaces thread_locals with
appropriate  __emultls_get_address calls ?


2017-02-08 14:53 GMT+00:00 Tim Northover <t.p.northover at gmail.com>:

> On 8 February 2017 at 04:57, Gaetano Checinski
> <gaetano.checinski at gmail.com> wrote:
> > What exactly do the compiler flags`-femulated-tls` and `tls-model` do ?
> > Why does tls-emulation not solve the problem ?
>
> It requires runtime support, specifically the __emultls_get_address
> function by the looks of it. That's not available on all platforms
> (it's not supplied by macOS for example) and is likely to be slower
> than native TLS if it is.
>
> > Looking at the generated IR, it seems not to remove thread_local
> variable declarations.
> > What is the reasoning behind that ?
>
> Using "-emit-llvm" doesn't actually print out the very final form of
> the LLVM IR. There are a few passes that run on the IR but are
> considered part of the final "CodeGen" phase. As a rule of thumb those
> are passes that are required for correctness reasons, in this case
> because without the LowerEmuTLS.cpp pass affected backends couldn't
> handle TLS constructs.
>
> Unfortunately it doesn't look like lli has support for emulated TLS
> either, though that would be pretty simple to add.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170208/97721e1a/attachment.html>