search for: setoptlevel

I run large piece of code in JIT and it runs only marginallty faster with optimization levels 1,2,3. I think differences are within the margin or error. level user time 0 17339ms 1 16913ms 2 16891ms 3 16898ms Level is set with builder->setOptLevel(olev); Compilation time is excluded by taking the only top-level function address before the run with getPointerToFunction. So I measure time without getPointerToFunction. Why optimization almost doesn't speed it up? What are the other than setOptLevel ways to control optimization? My mind...

...id>::visit() at 0xa26b4e llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa .... So the segfaults happens because of the memcpy call in the LoadIntFromMemory function in ExecutionEngine.cpp on line 887... Any clue ? Adding .setOptLevel(llvm::CodeGenOpt::None) to the EngineBuilder creation reduces the time by 25% but that is still not enough :( 2010/11/3 Török Edwin <edwintorok at gmail.com> > On Wed, 3 Nov 2010 11:18:34 +0000 > Salomon Brys <salomon.brys at gmail.com> wrote: > > > Jiting with no opti...

I am trying to JIT some code containing an indirect branch (and the corresponding store i8* blockaddress(@label)). I am using LLVM 2.7 code base. I build the ExecutionEngine using EngineBuilder, and call engine->getPointerToFunction(func). When I use setOptLevel(llvm::CodeGenOpt::None), the JITing fails with the following message : JIT.h:131: virtual void* llvm::JIT::getPointerToBasicBlock(llvm::BasicBlock*): Assertion `0 && "JIT does not support address-of-label yet!"' failed. However, when I use setOptLevel(llvm::CodeGenOpt::Less)...

...t away with > it when using the JIT. Try running under valgrind (either the interpreter or, > if you can, make a real program out of your bitcode and run that under > valgrind). > > Ciao, > > Duncan. > > > > > > > Adding .setOptLevel(llvm::CodeGenOpt::None) to the EngineBuilder > > creation reduces the time by 25% but that is still not enough :( > > > > > > 2010/11/3 Török Edwin<edwintorok at gmail.com <mailto:edwintorok at gmail.com>> > > > >> On...

...; IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? I tried to play with TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule); builder.setOptLevel(CodeGenOpt::Aggressive); builder.setEngineKind(EngineKind::JIT); builder.setUseMCJIT(true); builder.setCodeModel(CodeModel::JITDefault); builder.setMCPU(llvm::sys::getHostCPUName()); TargetOptions targetOptions; targetOptions.NoFramePointerElim = true; targetOptions...

Hi Morten, Something else just occurred to me: can you share your EngineBuilder configuration lines? (http://llvm.org/docs/doxygen/html/classllvm_1_1EngineBuilder.html) In particular - are you explicitly setting the optimization level? The old JIT may have had a different default. - Lang. Sent from my iPad > On Feb 4, 2016, at 10:54 PM, Jim Grosbach via llvm-dev <llvm-dev at

...text TheContext; unique_ptr<Module> Mod(new Module("A",TheContext)); llvm::EngineBuilder engineBuilder(std::move(Mod)); std::string mcjit_error; engineBuilder.setMCPU(llvm::sys::getHostCPUName()); engineBuilder.setEngineKind(llvm::EngineKind::JIT); engineBuilder.setOptLevel(llvm::CodeGenOpt::Aggressive); engineBuilder.setErrorStr(&mcjit_error); llvm::TargetOptions targetOptions; targetOptions.AllowFPOpFusion = llvm::FPOpFusion::Fast; engineBuilder.setTargetOptions( targetOptions ); TargetMachine *targetMachine = engineBuilder.selectTarget(); a...

...tants and variables) are complied to a long series off <add>s both in IR and assembly code. Both GCC and MSVC generates C1*x +C2 (mov + mul + add). I am new to using LLVM. I am using Visual Studio 2008 on Windows, targeting 32-bit X86 code. I'm using LLVM as a library. I've added setOptLevel(CodeGenOpt::Aggressive) to the engine but with no effect. Please let me know if there are some optimization options/passes in LLVM that could optimize such example expressions as "1+x+1+x+1+x+1+x". Bob

...r *mp = getBitcodeModuleProvider(buffer, getGlobalContext(), &error_message); if( first_time ) { InitializeNativeTarget(); builder = new EngineBuilder(mp); builder->setEngineKind(EngineKind::JIT); CodeGenOpt::Level opt_level = CodeGenOpt::Default; builder->setOptLevel(opt_level); execution_engine = builder->create(); delete(builder); // lli doesn't do this - is it safe? } Module *module = mp->materializeModule(&error_message); for (Module::iterator I = module->begin(), E = module->end(); I != E; ++I) { Function *f...

On Nov 20, 2010, at 2:41 PM, Sdadsda Sdasdaas wrote: > And also the resulting assembly code is very poor: > > 00460013 movss xmm0,dword ptr [esp+8] > 00460019 movaps xmm1,xmm0 > 0046001C addss xmm1,xmm1 > 00460020 pxor xmm2,xmm2 > 00460024 addss xmm2,xmm1 > 00460028 addss xmm2,xmm0 > 0046002C movss dword ptr

...xecuted with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? > > I tried to play with TargetOptions without any success… > > Here is the kind of code we use to allocate the JIT: > > EngineBuilder builder(fResult->fModule); > builder.setOptLevel(CodeGenOpt::Aggressive); > builder.setEngineKind(EngineKind::JIT); > builder.setUseMCJIT(true); > builder.setCodeModel(CodeModel::JITDefault); > builder.setMCPU(llvm::sys::getHostCPUName()); > > TargetOptions targetOptions; > targetOptions.NoFramePointer...

...oes not support MC emission! Do I need to do anything else? Also, what's the code quality of MCJIT compared to the old JIT? As I'm basically compiling statically at runtime, I don't mind if LLVM spends time generating the code --- I'm using a module pass, eager code generation and setOptLevel(llvm::CodeGenOpt::Aggressive) --- and right now I'm extremely happy with the quality of the code being emitted for amd64. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "Of course, on a sufficiently small planet, 40 km/hr is, in fact, │ sufficient to punt the elastic spheric...

..., getGlobalContext(), > &error_message); > >   if( first_time ) { >       InitializeNativeTarget(); >       builder = new EngineBuilder(mp); >       builder->setEngineKind(EngineKind::JIT); >       CodeGenOpt::Level opt_level = CodeGenOpt::Default; >       builder->setOptLevel(opt_level); >       execution_engine = builder->create(); >       delete(builder);       // lli doesn't do this - is it safe? lli allocates the builder on the stack, so it is automatically destroyed on scope exit. >   } > >   Module *module = mp->materializeModule(&er...

...o the static compiler. > Is there an option that I can pass to the (MC)JITer to force it to use SelectionDAGISel? I'm also curious which passes/algorithms are used when I set the MCJIT option to true and the opt level to Aggressive. E.g: engineBuilder.setUseMCJIT(true); engineBuilder.setOptLevel(llvm::CodeGenOpt::Aggressive); I adapted lli.cpp to use MCJIT in my code. I get better performance now -- close to statically compiled native code, but still not exactly the same (about 10% slower). Thank you. -Baris Aktemur

...LLVM/Clang 2.9 release for OSX, on OSX 10.6.8, on a core i7 macbook pro. I'm compiling from C++ using Clang, and passing the compiled module to an ExecutionEngine created as follows: EE = llvm::EngineBuilder(globalModule) .setEngineKind(llvm::EngineKind::JIT) .setErrorStr(&err) .setOptLevel(llvm::CodeGenOpt::Default) .setAllocateGVsWithCode(false) //.setMAttrs("-avx") .setMCPU("core2") .create(); EE->DisableLazyCompilation(); After passing in the compiled module, I call: EE->runStaticConstructorsDestructors(module, false); Then to test the tear...

...t;A",TheContext)); >> >> llvm::EngineBuilder engineBuilder(std::move(Mod)); >> std::string mcjit_error; >> >> engineBuilder.setMCPU(llvm::sys::getHostCPUName()); >> >> engineBuilder.setEngineKind(llvm::EngineKind::JIT); >> engineBuilder.setOptLevel(llvm::CodeGenOpt::Aggressive); >> engineBuilder.setErrorStr(&mcjit_error); >> >> llvm::TargetOptions targetOptions; >> targetOptions.AllowFPOpFusion = llvm::FPOpFusion::Fast; >> engineBuilder.setTargetOptions( targetOptions ); >> >> TargetMach...

..., compared to what we had with LLVM 3.1. What could be the reason? >> >> I tried to play with TargetOptions without any success… >> >> Here is the kind of code we use to allocate the JIT: >> >> EngineBuilder builder(fResult->fModule); >> builder.setOptLevel(CodeGenOpt::Aggressive); >> builder.setEngineKind(EngineKind::JIT); >> builder.setUseMCJIT(true); >> builder.setCodeModel(CodeModel::JITDefault); >> builder.setMCPU(llvm::sys::getHostCPUName()); >> >> TargetOptions targetOptions; >> targe...

...via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Hal, > > We are using the default register allocator. I assume the greedy one is > default? > > As for other target machine optimizations: > > I have tried: > > llvm::TargetMachine* tm = ...; > > tm->setOptLevel(llvm::CodeGenOpt::Aggressive); > > And it doesn't make much of a difference. > > And also: > > tm->setFastISel(true); > > (previous email). > > Is there anything else I can try? > > > On 05/02/16 11:16, Hal Finkel wrote: >> >> ----- Original...

...e); auto externalFn_llvm = Function::Create(FT, Function::ExternalLinkage, externalFnName, pModule); auto ret = builder.CreateCall(externalFn_llvm, x); builder.CreateRet(ret); errs() << "Created Module:\n\n" << *pModule; auto jitCompiler = EngineBuilder(std::move(module)).setOptLevel(CodeGenOpt::Level::Default).create(); JitCompiledFn externalFn = (JitCompiledFn)jitCompiler->getFunctionAddress(externalFn_IR->getName()); errs() << "\n\nexternalFn(9.0) = "; double y = externalFn(9.0); errs() << y << "\n\n"; return 0; } Kind reg...

...;llvm::SectionMemoryManager>(), std::move(Resolver)); } else { // MCJIT std::string engine_errors; llvm::EngineBuilder engine_builder (std::move(M)); engine_builder.setEngineKind (llvm::EngineKind::JIT) .setOptLevel (llvm::CodeGenOpt::Default) // Aggressive? .setErrorStr (&engine_errors); EE.reset (engine_builder.create()); EE->finalizeObject (); } // Ask for a callable function typedef float (*FuncFloatFloat)(float); FuncFloatFloat my_executable_fu...