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

> 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_Result_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/20170207/01d77559/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.ll
Type: application/octet-stream
Size: 814 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170207/01d77559/attachment.obj>

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_
>> Result_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/20170207/7031b421/attachment.html>

I should have mentioned that I run it on OS X and i doesn’t work =\
IR also attached.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.ll
Type: application/octet-stream
Size: 1383 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170207/0bd53dbd/attachment.obj>
-------------- next part --------------
> On 7 Feb 2017, at 17:19, Gaetano Checinski <gaetano.checinski at
gmail.com> wrote:
> 
> > 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_Result_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
> 
> 
> <main.ll>

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>