4 ms·
There are many optimizations in GCC and LLVM. If you turn them all off you will compile fast and execute slow, and if you turn them all on you will compile slo
by foobarbazqux 13y ago
There are many optimizations in GCC and LLVM. If you turn them all off you will compile fast and execute slow, and if you turn them all on you will compile slow and execute fast. You can do this on a per function / trace / translation unit / whatever basis.
Production JIT compilers are the same way. For the hottest code paths, all the optimizations get turned on. The coldest ones are interpreted. The first level of jitted compilation has very few optimizations enabled.
The main thing that doesn't cooperate with JIT compilation yet is whole program analysis.
- rayiner 13y agoThat's not actually true, at least with regards to LLVM. The vast majority of the time in LLVM is spent in instruction selection. LLVM spends a lot of time on instruction selection/legalization, which you can't just turn off.
- foobarbazqux 13y agoBut you can't turn off codegen in a JIT compiler either, unless you're interpreting code, so that requirement doesn't fundamentally make GCC and LLVM impractical. It sounds like LLVM either doesn't have very many optimizations or their backend needs work.
- rayiner 13y agoLLVM's instruction selection/legalization infrastructure is very sophisticated, very generic, table-driven, etc. Most JIT compilers use more ad-hoc and quicker mechanisms to get machine code out of IR.
- foobarbazqux 13y agoYeah okay. Someone else pointed out FastISel.cpp. It's probably true that prettiness competes with performance.
- rayiner 13y agoFastISel will quite often kick out to the regular instruction selector because it can't handle particular IR constructs.
- pcwalton 13y agoWell, you can use FastISel, which is way way faster (it's a simple non-pattern-matching instruction emitter, like the Plan 9 compilers).