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

What exactly do the compiler flags`-femulated-tls` and `tls-model` do ?
Why does tls-emulation not solve the problem ?

Looking at the generated IR, it seems not to remove thread_local variable
declarations.
What is the reasoning behind that ?


2017-02-07 16:27 GMT+00:00 Gaetano Checinski <gaetano.checinski at
gmail.com>:
>
> got a minimal example now:
>     extern thread_local int tls;
>     int main() {
>         tls = 42;
>         return 0;
>     }
>
> llvm-ir:
>     ; ModuleID = 'main.cpp'
>     target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
>     target triple = "x86_64-pc-linux-gnu"
>
>     @tls = thread_local global i32 0, align 4
>
>     ; Function Attrs: norecurse uwtable
>     define i32 @main() #0 {
>       %1 = alloca i32, align 4
>       store i32 0, i32* %1, align 4
>       %2 = call i32* @_ZTW3tls()
>       store i32 37, i32* %2, align 4
>       ret i32 0
>     }
>
>     define weak_odr hidden i32* @_ZTW3tls() {
>       ret i32* @tls
>     }
>
>     attributes #0 = { norecurse uwtable
"disable-tail-calls"="false"
> "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
> "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
> "no-nans-fp-math"="false"
"stack-protector-buffer-size"="8"
> "target-cpu"="x86-64"
"target-features"="+fxsr,+mmx,+sse,+sse2"
> "unsafe-fp-math"="false"
"use-soft-float"="false" }
>
>     !llvm.ident = !{!0}
>
>     !0 = !{!"clang version 3.8.1-12 (tags/RELEASE_381/final)"}
>
>
> 2017-02-07 16:19 GMT+00:00 Gaetano Checinski <gaetano.checinski at
gmail.com>
> :
>
>> > I’ve seen the same problem, but didn’t find solution back then.
>> > I can give a hint that it is related to a thread local storage
(notice
>> TLS in the name).
>> >
>> > The same result can be reproduced by this simple program:
>> >
>> >    thread_local int x = 0;
>> >    int main() {
>> >      return 0;
>> >    }
>> >
>> >When compiled into IR it produces similar error:
>> >
>> >LLVM ERROR: Cannot select: t19: i64 = X86ISD::WrapperRIP
>> TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=19]
>> >  t18: i64 = TargetGlobalTLSAddress<i32* @x> 0 [TF=19]
>> >In function: _ZTW1x
>>
>> interestingly this works on my machine.
>>
>> llvm-ir attached
>>
>>
>>
>> 2017-02-07 15:31 GMT+00:00 Alex Denisov <1101.debian at
gmail.com>:
>>
>>> I’ve seen the same problem, but didn’t find solution back then.
>>> I can give a hint that it is related to a thread local storage
(notice
>>> TLS in the name).
>>>
>>> The same result can be reproduced by this simple program:
>>>
>>>     thread_local int x = 0;
>>>     int main() {
>>>       return 0;
>>>     }
>>>
>>> When compiled into IR it produces similar error:
>>>
>>> LLVM ERROR: Cannot select: t19: i64 = X86ISD::WrapperRIP
>>> TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=19]
>>>   t18: i64 = TargetGlobalTLSAddress<i32* @x> 0 [TF=19]
>>> In function: _ZTW1x
>>>
>>> > On 7 Feb 2017, at 16:13, Mehdi Amini via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>> >
>>> > + LLVM-dev (clang is mostly about the frontend and this is a
backend
>>> failure), you may have more change to get an answer.
>>> >
>>> >> On Feb 6, 2017, at 5:49 AM, Gaetano Checinski via cfe-dev
<
>>> cfe-dev at lists.llvm.org> wrote:
>>> >>
>>> >> Running the following code with clang++ -S -emit-llvm
main.cpp && lli
>>> main.ll on Linux(Debian)
>>> >>
>>> >> #include <future>
>>> >>
>>> >>
>>> >>
>>> >> int main () {
>>> >>
>>> >>
>>> >> return std::async([]{return 1;}).get();
>>> >> }
>>> >> fails to run on lli due to the following error:
>>> >>
>>> >> LLVM ERROR: Cannot select: 0xd012e0:
>>> >>
>>> >>      i64
>>> >> = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8**
>>> @_ZSt15__once_callable> 0 [TF=10]
>>> >>
>>> >>
>>> >>
>>> >> 0xd020c0: i64 = TargetGlobalTLSAddress<i8**
@_ZSt15__once_callable> 0
>>> [TF=10]
>>> >> In function: _ZSt9call_onceIMNSt13__future_
>>> base13_State_baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_Re
>>> sult_baseENS4_8_DeleterEEvEEPbEJPS1_S9_SA_EEvRSt9once_flagOT_DpOT0_
>>> >> Questions:
>>> >>
>>> >> What does it mean?
>>> >>
>>> >> Are there any compiler-flags that fix this problem?
>>> >>
>>> >> what specific features is libstdc++ using that cause this
issue ?
>>> >>
>>> >> How does my problem relate to Bug 21431 ?
>>> >>
>>> >> The motivation behind this questions is to understand the
differences
>>> between libc++ and libstdc++ that leads to this specific error
message (on
>>> Linux) in llvm's orcjit.
>>> >>
>>> >>
>>> >>
>>> >> ps.: i've also asked this question in stackoverflow
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>  Sent with Mailtrack
>>> >>
>>> >> _______________________________________________
>>> >> cfe-dev mailing list
>>> >> cfe-dev at lists.llvm.org
>>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>> >
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > cfe-dev at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170208/cb6067f1/attachment.html>

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.

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