[LLVMdev] Using LLVM to serialize object state -- and performance

Kaylor, Andrew andrew.kaylor at intel.com
Tue Nov 13 18:15:05 PST 2012


The passes run are determined by TargetMachine::adPassesToEmitMachineCode (or addPassesToEmitMC in the case of MCJIT), which is called from the JIT constructor.  You can step through that to see where the passes are coming from or you can create a custom target machine instance to control it.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Paul J. Lucas
Sent: Tuesday, November 13, 2012 4:33 PM
To: llvmdev at cs.uiuc.edu List
Subject: Re: [LLVMdev] Using LLVM to serialize object state -- and performance

I've been profiling more; see <https://dl.dropbox.com/u/46791180/perf.png>.

One thing I'm a bit confused about is why I see a FunctionPassManager there.  I use a FunctionPassManager at the end of LLVM IR code generation, write the IR to disk, then read it back later.

Why is apparently another FunctionPassManager being used during the JIT'ing of the IR code?  And how do I control what the passes are to that FunctionPassManager?

The function that's being JIT'd has to executed only once so, ideally, I want to find a sweet spot between speed-of-JIT'ing and speed-of-generated-machine code.

- Paul

On Nov 13, 2012, at 11:27 AM, Paul J. Lucas <paul at lucasmail.org> wrote:

> Switching to CodeGenOpt::None reduced the execution time from 5.74s to 0.84s.  By just tweaking things randomly, changing to CodeModel::Small reduced it further to 0.22s.
> 
> We have some old, ugly, pure C++ code that we're trying to replace (both because it's ugly and because it's slow).  It's execution time is about 0.089s, so that's the time to beat.
> 
> Hence, I'd like to reduce the 0.22s time even further to below 0.089s.  Any ideas?

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list