[LLVMdev] What makes register allocation expensive?
Mars Saxman
mars at redecho.org
Mon Oct 7 19:02:31 PDT 2013
Compile times increased by roughly 20X after upgrading the Radian
compiler project from LLVM 3.1 to 3.3. I am curious whether this is
considered normal. If it is not, I would appreciate some help figuring
out what it is about the Radian compiler's output which is causing LLVM
to spend so much time compiling such small programs.
I recorded these times with Apple's Xcode Instruments (version 4.6.1).
The input is the most basic program in the test suite; it prints "hello,
world" and counts from 1 to 10, so it is about a dozen lines long and
refers to maybe five hundred lines of library code. All times are in
milliseconds, and the total includes both compilation and program
execution.
llvm-3.1:
2722 total
2342 llvm::ExecutionEngine::runFunctionAsMain
1144 SelectionDAGIsel::runOnMachineFunction
294 RegisterCoalescer::runOnMachineFunction
116 RAGreedy::runOnMachineFunction
llvm-3.3:
53683 total
52661 llvm::ExecutionEngine::runFunctionAsMain
16955 RAGreedy::runOnMachineFunction
15149 RegisterCoalescer::runOnMachineFunction
15072 SelectionDAGIsel::runOnMachineFunction
Both cases use createJIT with default values, so optimization is
presumably llvm::CodeGenOpt::Default.
Disabling optimization yields a more reasonable run time with llvm-3.3:
1028 total
712 llvm::ExecutionEngine::runFunctionAsMain
491 SelectionDAGISel::runOnMachineFunction
85 RAFast::runOnMachineFunction
But even llvm::CodeGenOpt::Less has become very expensive:
7633 total
7307 llvm::ExecutionEngine::runFunctionAsMain
3386 SelectionDAGISel::runOnMachineFunction
1311 RAGreedy::runOnMachineFunction
1157 RegisterCoalescer::runOnMachineFunction
What might have changed between LLVM 3.1 and 3.3 which would cause such
a dramatic change in compile times?
Thank you for any suggestions of places I should begin to look.
More information about the llvm-dev
mailing list