lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev

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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
+ 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
In reply to this post by Nat! via cfe-dev
On 6 February 2017 at 03:49, Gaetano Checinski via cfe-dev
<[hidden email]> wrote:
> 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?

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

That's a compilation mode where the assembly is emitted that can run
from anywhere in memory. During normal compilation "small" is used,
the compiler assumes code will end up in the low 2GB of memory, and
the linker makes sure this is true.

Unfortunately when JITing, you can't usually guarantee that the OS
will give you memory in the low 2GB so the default is "large", which
is obviously less robust since it's less commonly used.

> Are there any compiler-flags that fix this problem?

Unfortunately it doesn't seem so. Using "lli -relocation-model=pic"
gets around the immediate problem but then the JIT dynamic loader
can't cope with the relocations that get generated.
> what specific features is libstdc++ using that cause this issue ?

Any thread-local storage would do it.

> How does my problem relate to Bug 21431?

Looks like exactly the same issue.

Cheers.

Tim.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
Thanks for your quick answer.

> It's a missing feature/bug in the x86 backend
did anyone try to implement an IR-transformer to emulate thread_local ?

JIT dynamic loader an't cope with the relocations that get generated.
how difficult would it be to fix this ?


2017-02-07 15:35 GMT+00:00 Tim Northover <[hidden email]>:
On 6 February 2017 at 03:49, Gaetano Checinski via cfe-dev
<[hidden email]> wrote:
> 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?

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

That's a compilation mode where the assembly is emitted that can run
from anywhere in memory. During normal compilation "small" is used,
the compiler assumes code will end up in the low 2GB of memory, and
the linker makes sure this is true.

Unfortunately when JITing, you can't usually guarantee that the OS
will give you memory in the low 2GB so the default is "large", which
is obviously less robust since it's less commonly used.

> Are there any compiler-flags that fix this problem?

Unfortunately it doesn't seem so. Using "lli -relocation-model=pic"
gets around the immediate problem but then the JIT dynamic loader
can't cope with the relocations that get generated.
> what specific features is libstdc++ using that cause this issue ?

Any thread-local storage would do it.

> How does my problem relate to Bug 21431?

Looks like exactly the same issue.

Cheers.

Tim.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
In reply to this post by Nat! via cfe-dev
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

main.ll (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev

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 <[hidden email]>:
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


<img width="0" height="0" class="m_-2125643818949585300mailtrack-img" src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">

2017-02-07 15:31 GMT+00:00 Alex Denisov <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
In reply to this post by Nat! via cfe-dev
I should have mentioned that I run it on OS X and i doesn’t work =\
IR also attached.



> On 7 Feb 2017, at 17:19, Gaetano Checinski <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email]
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> > _______________________________________________
> > cfe-dev mailing list
> > [hidden email]
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> <main.ll>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

main.ll (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
In reply to this post by Nat! via cfe-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 <[hidden email]>:

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)"}

<img width="0" height="0" class="m_6975110549045232005mailtrack-img" src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">

2017-02-07 16:19 GMT+00:00 Gaetano Checinski <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev





_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
On 8 February 2017 at 04:57, Gaetano Checinski
<[hidden email]> 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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-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 <[hidden email]>:
On 8 February 2017 at 04:57, Gaetano Checinski
<[hidden email]> 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.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Nat! via cfe-dev
On 8 February 2017 at 09:50, Gaetano Checinski
<[hidden email]> 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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev