[LLVMdev] Fixing exterme inefficiency in debug printings.

Gil Dogon Gil.Dogon at mobileye.com
Sun Feb 15 02:35:44 PST 2015


Hello.

I am developing a proprietary back end based on LLVM for my employer. As part of debbuging it I use the -debug command line option , and  sometimes insert debug prints such as

DEBUG( dbgs() << ....)

which print some intermediate LLVM Values.

I have noticed that running with those prints is EXTEREMLY slow, so I decide to take a look at
it and see what the reason is.

Well using a debugger the problem was obvious, and it appears in lib/IR/AsmWriter.cpp:

The code of the function Value::print for example has this:


if (const Instruction *I = dyn_cast<Instruction>(this)) {
   const Function *F = I->getParent() ? I->getParent()->getParent() : nullptr;
   SlotTracker SlotTable(F);
   AssemblyWriter W(OS, SlotTable, getModuleFromVal(I), nullptr);
   W.printInstruction(*I);
}


And similar other cases.
The problem is that the    SlotTracker  and AssemblyWriter objects which are
created every time for every Value involves very heavy initialization.

It can be circumvented quite easily by inserting internal "Caching" of  static
variables for those objects, so that initialization is done automaticaly only in
case the Module or Function was changed since last usage ...

I did it localy in my tree and it improved performance to reasonable levels, but I work with a dated version of LLVM, so humbly suggest that maybe some of the maintainers of this code do  the same ...




This mail was sent via Mail-SeCure system.



 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150215/fdaed614/attachment.html>


More information about the llvm-dev mailing list