search for: checinski

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

...x TLS for linux. Unfortunately it is based on llvm3.6 and uses RuntimeDyLdELF::findGOTEntry. Is there any equivalent method in llvm4.0 ? 2017-02-08 19:40 GMT+00:00 Tim Northover <t.p.northover at gmail.com>: > [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_ad...

...ver 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 i...

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 > <https://mailtrack.io/trace/link/60b02baa5e1b3d7ffe6fbb428b343be17c58c583?url=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fllvm%2Fcommit%2Fa9e17b7f47f5afa9683fc8cfeff7020b2ff4a8b2%23diff-0fa8ca8690e36a8dfd0...

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

[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 no...

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

Is it possible to inline functions compiled from C++ code into generated code that is fed, Module by Module, into the ORC JIT? I'd like to add a Module compiled from C++ code into the JIT and then as I add later modules, functions from the first module are inlined in the later ones. I already do this for file compilation/linking in my Common Lisp compiler “Clasp” (github.com/drmeister/clasp