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

> 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>

On 8 February 2017 at 09:50, Gaetano Checinski
<gaetano.checinski at gmail.com> wrote:
> > 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 ?
Oh, interesting. Looks like the pass only does a pretty small part of
the work. The rest happens to the DAG in
TargetLowering::LowerToTLSEmulatedModel, based on
TargetOptions::EmulatedTLS (there's a reasonable chance that would
also automatically add the pass).

Tim.

[Adding llvm-dev back to list]

On 8 February 2017 at 11:12, Gaetano Checinski
<gaetano.checinski at gmail.com> wrote:
> Thanks for sharing your insights,
> so in theory i could build an llvm pass that calls
TargetLowering::LowerToTLSEmulatedModel for each llvm::Function and it should
work if i link a runtime that provides __emultls_get_address.
I'm afraid not, that function is called as part of converting from a
Function to a MachineFunction. It operates on a completely different
representation to normal LLVM IR. The only way to trigger it is to set
the right field in the TargetOptions.
> >It's a missing feature/bug in the x86 backend. The specific problem
is
> >that it seems we don't support thread-local variables with what
Clang
> >& GCC would call "-mcmodel=large".
>
> Would it be a better approach to fix this issue ?
Yes, I think that'd be the proper fix for the issue. It's possible the
JIT parts don't support TLS at all yet either, which would mean we
have to implement it there.
> How difficult would it be ?
I don't think there are any fundamental difficulties; the ABI already
exists because GCC can cope. On the JIT side, it'll be a case of
supporting some relocations (pretty simple) and getting the output
object's thread-local sections registered with the system somehow
(more difficult, I'm not sure what each platform's callbacks are).

It's probably measured in days even for someone who knows many of the
details already though.

Cheers.

Tim.

I'm looking currently into a patch
<https://mailtrack.io/trace/link/60b02baa5e1b3d7ffe6fbb428b343be17c58c583?url=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fllvm%2Fcommit%2Fa9e17b7f47f5afa9683fc8cfeff7020b2ff4a8b2%23diff-0fa8ca8690e36a8dfd05f6b751955164R339&signature=222c65b9d92c011f>
which has been written for JuliaLang and is supposed to fix TLS for linux.
Unfortunately it is based on llvm3.6 and uses RuntimeDyLdELF::findGOTEntry.
Is there any equivalent method in llvm4.0 ?


2017-02-08 19:40 GMT+00:00 Tim Northover <t.p.northover at gmail.com>:
> [Adding llvm-dev back to list]
>
> On 8 February 2017 at 11:12, Gaetano Checinski
> <gaetano.checinski at gmail.com> wrote:
> > Thanks for sharing your insights,
> > so in theory i could build an llvm pass that calls
TargetLowering::LowerToTLSEmulatedModel
> for each llvm::Function and it should work if i link a runtime that
> provides __emultls_get_address.
>
> I'm afraid not, that function is called as part of converting from a
> Function to a MachineFunction. It operates on a completely different
> representation to normal LLVM IR. The only way to trigger it is to set
> the right field in the TargetOptions.
>
> > >It's a missing feature/bug in the x86 backend. The specific
problem is
> > >that it seems we don't support thread-local variables with
what Clang
> > >& GCC would call "-mcmodel=large".
> >
> > Would it be a better approach to fix this issue ?
>
> Yes, I think that'd be the proper fix for the issue. It's possible
the
> JIT parts don't support TLS at all yet either, which would mean we
> have to implement it there.
>
> > How difficult would it be ?
>
> I don't think there are any fundamental difficulties; the ABI already
> exists because GCC can cope. On the JIT side, it'll be a case of
> supporting some relocations (pretty simple) and getting the output
> object's thread-local sections registered with the system somehow
> (more difficult, I'm not sure what each platform's callbacks are).
>
> It's probably measured in days even for someone who knows many of the
> details already though.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170209/9267a6c7/attachment.html>