search for: wrapperrip

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

...rage (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 sa...

...s 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 >> >> >> >> 20...

Over one year passed now, did anybody made any progress regarding this issue? On 9 February 2017 at 16:33, Gaetano Checinski <gaetano.checinski at gmail.com> wrote: > I'm looking currently into a patch >

[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

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

...ORD=109] [ID=8] 0x30cc5a8: i32 = shl 0x30cc2d8, 0x30ccc68 [ORD=109] [ID=7] 0x30cc2d8: i32,ch = CopyFromReg 0x30a6168, 0x30cc908 [ORD=109] [ID=5] 0x30cc908: i32 = Register %vreg29 [ID=1] 0x30ccc68: i8 = Constant<2> [ID=4] 0x30cc518: i32 = X86ISD::WrapperRIP 0x30ccab8 [ID=6] 0x30ccab8: i32 = TargetJumpTable<0> [ID=3] 0x30cc6c8: i32 = undef [ID=2] 0x30cc518: i32 = X86ISD::WrapperRIP 0x30ccab8 [ID=6] 0x30ccab8: i32 = TargetJumpTable<0> [ID=3] In function: __atomic_compare_exchange clang: error: clang frontend command...

> 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

Ah, I've replied in a different thread already. What Dmitri says - If you're interesting in only building the Clang on x32 host, you may avoid checking out compiler-rt repo for now. On Thu, Aug 22, 2013 at 10:59 AM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <steve at snewbury.org.uk> > wrote: > > I've

Currently it appears X86WrapperRIP is only implemented in the small code model, which causes code to fail to select in other code models. My particular use case is MCJIT, where the default code model is large (the X86WrapperRIP comes from a TLS variable reference). What would be the best way to implement this? I'd be happy to ta...