That'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.
But 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.
LLVM'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.
Comments
That'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.
Well, you can use FastISel, which is way way faster (it's a simple non-pattern-matching instruction emitter, like the Plan 9 compilers).
But 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.
LLVM'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.
Yeah okay. Someone else pointed out FastISel.cpp. It's probably true that prettiness competes with performance.
FastISel will quite often kick out to the regular instruction selector because it can't handle particular IR constructs.