llvm dev - Jun 2010 - [LLVMdev] Why code doesn't speed up much with optimization level increase?

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 mindset is defined by experience with gcc, when increasing inlining 
levels speeds the code up significantly. Does JIT inline at all?
It's hard to believe that even only local (no inlining) optimization 
wouldn't bring timing down by at least 10%.

i386 on i7
r106715

Yuri

On Fri, Jun 25, 2010 at 3:06 PM, Yuri <yuri at rawbw.com>
wrote:
> 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 mindset is defined by experience with gcc, when increasing inlining
> levels speeds the code up significantly. Does JIT inline at all?
> It's hard to believe that even only local (no inlining) optimization
> wouldn't bring timing down by at least 10%.
>
> i386 on i7
> r106715
Are you running IR-level optimizations?  There's only so much the code
generator can do with unoptimized IR...

-Eli

It seems to me that you're not running any LLVM IR optimization passes
before JIT'ing the code.

In my code, I have:

PassManager*		m_PassManager;

// Adds the same module passes as -O3. Copied from opt.cpp in the
// llc - llvm compiler codeline.
Pass *inliningPass = createFunctionInliningPass();
createStandardModulePasses(	m_PassManager, 3,
				/*OptimizeSize=*/ false										/*UnitAtATime=*/ true,
				/*UnrollLoops=*/ true,
				/*SimplifyLibCalls=*/ true,
				/*HaveExceptions=*/ true,
				inliningPass );

( the 3 is the optimization level) and then later:

// Run the optimization passes for the module.
m_PassManager->run( *m_Module );

I also optionally have a call to:

m_PassManager->add( createPrintModulePass( &dbgs() ) );

before this which outputs the pre-optimized code to the debug stream. I dump the
module after running the optimization passes and it's pretty easy to see
what changes have been made to the LLVM IR.  They are generally quite
significant as the optimizer passes do some amazing things.

createStandardModulePasses

is the code used by llc to optimize the LLVM IR, so passing a 3 as the
optimization level parameter is the equivalent to passsing -O3 to llc. It adds a
ton of different optimization passes. You can find the code for it in the file
opt.cpp.

- Curtis


n Jun 25, 2010, at 6:06 PM, Yuri wrote:
> 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 mindset is defined by experience with gcc, when increasing inlining 
> levels speeds the code up significantly. Does JIT inline at all?
> It's hard to believe that even only local (no inlining) optimization 
> wouldn't bring timing down by at least 10%.
> 
> i386 on i7
> r106715
> 
> Yuri
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100625/387aee78/attachment.html>

One more thing. If you really want to find out what's going on at each pass
of the optimization process. Place this code:

// If this is set to 1 then the JIT engine will print out machine code
// between optimization passes.
llvm::PrintMachineCode = 0;

somewhere before running the pass manager, and it will print out the LLVM IR
after every single optimization pass. It doesn't really print out machine
code but it prints out an LLVM IR assembly language dump of the module.

- Curtis


On Jun 25, 2010, at 6:06 PM, Yuri wrote:
> 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 mindset is defined by experience with gcc, when increasing inlining 
> levels speeds the code up significantly. Does JIT inline at all?
> It's hard to believe that even only local (no inlining) optimization 
> wouldn't bring timing down by at least 10%.
> 
> i386 on i7
> r106715
> 
> Yuri
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100625/fb55ec0c/attachment.html>