similar to: [LLVMdev] Slow jitter.

Eli Friedman <eli.friedman at gmail.com> writes: > On Wed, Aug 26, 2009 at 1:10 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> While compiling some sources, translating from my compiler's IR to LLVM >> using the C++ API requires 2.5 seconds. If the resulting LLVM module is >> dumped as LLVM assembler, the file is 240,000 lines long. Generating >> LLVM

On Wed, Aug 26, 2009 at 1:10 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: > While compiling some sources, translating from my compiler's IR to LLVM > using the C++ API requires 2.5 seconds. If the resulting LLVM module is > dumped as LLVM assembler, the file is 240,000 lines long. Generating > LLVM code is fast. > > However, generating the native code is quite slow: 33

On Tue, Aug 25, 2009 at 4:58 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> On Wed, Aug 26, 2009 at 1:10 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >>> While compiling some sources, translating from my compiler's IR to LLVM >>> using the C++ API requires 2.5 seconds. If the resulting LLVM

Eli Friedman <eli.friedman at gmail.com> writes: > On Tue, Aug 25, 2009 at 4:58 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> Eli Friedman <eli.friedman at gmail.com> writes: >> >>> On Wed, Aug 26, 2009 at 1:10 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >>>> While compiling some sources, translating from my compiler's IR to LLVM

On Aug 25, 2009, at 1:40 PM, Óscar Fuentes wrote: > While compiling some sources, translating from my compiler's IR to > LLVM > using the C++ API requires 2.5 seconds. If the resulting LLVM module > is > dumped as LLVM assembler, the file is 240,000 lines long. Generating > LLVM code is fast. > > However, generating the native code is quite slow: 33 seconds. I

Chris Lattner <clattner at apple.com> writes: > The JIT uses the entire code generator, which uses N^2 algorithms etc > in some cases. If you care about compile time, I'd strongly suggest > using the "local" register allocator and the "-fast" mode. This is > what we do for -O0 compiles and it is much much faster than the > defaults. Okay,

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: >> If I activate the Inliner pass: >> >>    Builder.Inliner = createFunctionInliningPass(Threshold); >> >> this is the result: >> >> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >> >> It happens on almost all my test

Albert Graef <Dr.Graef at t-online.de> writes: > Óscar Fuentes wrote: >> Okay, I'll do if some day I figure out how to pass those options to the >> JIT :-) > > Well, the -fast option is easy to get: > > MP = new ExistingModuleProvider(module); > string error; > JIT = ExecutionEngine::create(MP, false, &error, llvm::CodeGenOpt::None); Thanks

Óscar Fuentes wrote: > Okay, I'll do if some day I figure out how to pass those options to the > JIT :-) Well, the -fast option is easy to get: MP = new ExistingModuleProvider(module); string error; JIT = ExecutionEngine::create(MP, false, &error, llvm::CodeGenOpt::None); Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email:

On Aug 26, 2009, at 6:57 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > > Yup, llc -O0 takes 37.5 seconds. > > llc -pre-RA-sched=fast -regalloc=local takes 26 seconds. Another important flag for testing llc time is llc -asm-verbose=false. Dan

Óscar Fuentes <ofv at wanadoo.es> writes: >>> If I activate the Inliner pass: >>> >>>    Builder.Inliner = createFunctionInliningPass(Threshold); >>> >>> this is the result: >>> >>> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >>> >>> It happens on almost

Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As all "external" functions are provided by the language's FFI mechanism, it does MyExecutionEngine->DisableSymbolSearching(); MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); which works fine with the JIT. However, MCJIT insists on resolving unknown symbols by searching them

Albert Graef <Dr.Graef at t-online.de> writes: > Óscar Fuentes wrote: >> With this change the time used by code generation goes down from 33 >> seconds to 26.5. > > ... and that's probably not worth it because of the loss of code > quality. Agreed. The JIT with default options produces slightly slower code than a brain-dead alternative backend my compiler has. I

Óscar Fuentes <ofv at wanadoo.es> writes: > Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As > all "external" functions are provided by the language's FFI mechanism, > it does > > MyExecutionEngine->DisableSymbolSearching(); > MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); > > which works fine

Hello Török. Török Edwin <edwintorok at gmail.com> writes: > On 2009-08-26 16:57, Óscar Fuentes wrote: >> llc needs 45 seconds. This is far worse than the 33 seconds used by the >> JIT. Maybe llc is using optimizations. My JIT have no optimizations >> enabled. >> >> Yup, llc -O0 takes 37.5 seconds. >> >> llc -pre-RA-sched=fast -regalloc=local

On 2009-08-26 16:57, Óscar Fuentes wrote: > llc needs 45 seconds. This is far worse than the 33 seconds used by the > JIT. Maybe llc is using optimizations. My JIT have no optimizations > enabled. > > Yup, llc -O0 takes 37.5 seconds. > > llc -pre-RA-sched=fast -regalloc=local takes 26 seconds. Much better but > still slow IMO. The question is if this avoids the non-linear

Óscar Fuentes wrote: > With this change the time used by code generation goes down from 33 > seconds to 26.5. ... and that's probably not worth it because of the loss of code quality. In Pure I always use llvm::CodeGenOpt::Aggressive, although there's a preprocessor symbol to select llvm::CodeGenOpt::None at compile time. I also found that in Pure the lion's share of

On Aug 26, 2009, at 8:32 AM, Chris Lattner <clattner at apple.com> wrote: > On Aug 26, 2009, at 7:47 AM, Óscar Fuentes wrote: >>> Also if you use -time-passes with llc it should show which pass in >>> llc >>> takes so much time. >> >> These are the three main culprits for llc -O0 >> >> ---User Time--- --System Time-- --User+System--

I guess we'll have to add that to the list of things that needs to be done to replace the old JIT. In the projects I've worked on that use MCJIT, we've been using getPointerToFunction and then calling it from outside the MCJIT engine, but I suppose that the generic handling in runFunction would be useful in some cases. -Andy -----Original Message----- From: llvmdev-bounces at

Jianzhou Zhao <jianzhou at seas.upenn.edu> writes: [snip] > The other question is about > target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" > > If I use this string to creat a TargetData object directly, I got an > assertion error: > >