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

[Kaylor, Andrew]

Hi Paul,

This is definitely outside the area where I know the particulars of what's going on.  However, one idea that might be worth trying is setting the JIT optimization level to 'CodeGenOpt::None'.  This should trigger the use of the FastISel instruction selector.  Normally, you wouldn't want that for anything other than generating debug code, but since your routines are just making calls, it might work for you.

-Andy

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

On Nov 6, 2012, at 11:49 AM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:

> I think you may have gone beyond what I understand in how the legacy JIT code works.  It looks like the call to addGlobalMapping should short-circuit the named function look up that I described ...

Well, I first look for the function by name and, if I didn't find it, then I call addGlobalMapping().  But that's not where the time is going.  Here:

	https://dl.dropbox.com/u/46791180/callgraph.pdf

is a call graph generated by kcachegrind.  I still don't understand all the numbers (and this PDF seems not to include commas where it should), but if you look at the left fork, the bottom two ovals, "Schedule..." is called 16K times and "setHeightToAtLeas..." is called 37K times.  On the right fork, RAGreed... is called 35K times.

Those are far too many calls to *anything* for a simple sequence of "call" LLVM instructions.  Something seems horribly wrong.

- Paul


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