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

[Gaetano Checinski via llvm-dev]

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>