search for: nolazycompil

Sure, you can turn off lazy compilation. Take a look at NoLazyCompilation in lli.cpp. Evan On Jul 7, 2008, at 6:08 AM, Nicolas Capens wrote: > Hi all, > > Is there any way to generate the binary code for a whole module at > once? Currently I always get lazy compilation one function at a time. > > The reason I would like to generate the whole m...

Hi all, Is there any way to generate the binary code for a whole module at once? Currently I always get lazy compilation one function at a time. The reason I would like to generate the whole module at once is because I create some functions at run-time and then minimize the memory footprint by deallocating all LLVM objects. I've written my own JITMemoryManager to ensure that the binary

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

...aModules > std::vector<std::string>(), // ExtraObjects > std::vector<std::string>(), // ExtraArchives > false, // EnableCacheManager > std::string(), // ObjectCacheDir > std::string(), // FakeArgv0 > false, // DisableCoreFiles > false, // NoLazyCompilation > Reloc::PIC_, // RelocModel > CodeModel::JITDefault, // CMModel > true, // GenerateSoftFloatCalls > FloatABI::Soft, // FloatABIForCalls > false, // EmitJitDebugInfo > false // EmitJitDebugInfoToDisk > ); > > I'm getting the next erro...

Both Clang/LLVM 3.4 -> Clang/LLVM 3.5 And i will also try using MCJIT. 2014-09-17 18:56 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: > Hi, Tim. > > I've used Clang 3.4 final release and now i'm going to test it with 3.5 > release (since i've read about arm64 improvements). > I will report my results. > > BTW, is it possible to get smth like

...(), // ExtraObjects >>> std::vector<std::string>(), // ExtraArchives >>> false, // EnableCacheManager >>> std::string(), // ObjectCacheDir >>> std::string(), // FakeArgv0 >>> false, // DisableCoreFiles >>> false, // NoLazyCompilation >>> Reloc::PIC_, // RelocModel >>> CodeModel::JITDefault, // CMModel >>> true, // GenerateSoftFloatCalls >>> FloatABI::Soft, // FloatABIForCalls >>> false, // EmitJitDebugInfo >>> false // EmitJitDebugInfoToDisk &gt...

...::vector<std::string>(), // ExtraArchives >>>>> false, // EnableCacheManager >>>>> std::string(), // ObjectCacheDir >>>>> std::string(), // FakeArgv0 >>>>> false, // DisableCoreFiles >>>>> false, // NoLazyCompilation >>>>> Reloc::PIC_, // RelocModel >>>>> CodeModel::JITDefault, // CMModel >>>>> true, // GenerateSoftFloatCalls >>>>> FloatABI::Soft, // FloatABIForCalls >>>>> false, // EmitJitDebugInfo >>>&...

...JITEventListener::createOProfileJITEventListener()); > EE->RegisterJITEventListener( > JITEventListener::createIntelJITEventListener()); > + EE->RegisterJITEventListener( > + JITEventListener::createPerfJITEventListener()); > > if (!NoLazyCompilation && RemoteMCJIT) { > errs() << "warning: remote mcjit does not support lazy compilation\n"; > -- > 2.11.0.22.g8d7a455.dirty > > #include <stdint.h> > #include <stdbool.h> > > bool stupid_isprime(uint64_t num) > { > if (...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that