On Nov 19, 2009, at 1:04 PM, Bob Wilson wrote:>> I've tested it and LLVM is indeed 2x slower to compile, although it
>> generates
>> code that is 2x faster to run...
>>
>>> Compared to a compiler in the same category as PCC, whose pinnacle
of
>>> optimization is doing register allocation? I'm not surprised
at all.
>>
>> What else does LLVM do with optimizations turned off that makes it
>> slower?
>
> I haven't looked at Go at all, but in general, there is a significant
> overhead to creating a compiler intermediate representation. If you
> produce assembly code straight out of the parser, you can compile
> faster.
Right. Another common comparison is between clang and TCC. TCC generates
terrible code, but it is a great example of a one pass compiler that doesn't
even build an AST. Generating code as you parse will be much much much faster
than building an AST, then generating llvm ir, then generating assembly from it.
On X86 at -O0, we use FastISel which avoids creating the SelectionDAG
intermediate representation in most cases (it fast paths LLVM IR ->
MachineInstrs, instead of going IR -> SelectionDAG -> MachineInstrs).
I'm still really interested in making Clang (and thus LLVM) faster at -O0
(while still preserving debuggability of course). One way to do this (which
would be a disaster and not worth it) would be to implement a new X86 backend
directly translating from Clang ASTs or something like that. However, this
would obviously lose all of the portability benefits that LLVM IR provides.
That said, there is a lot that we can do to make the compiler faster at O0.
FastISel could be improved in several dimensions, including going bottom-up
instead of top-down (eliminating the need for the 'dead instruction
elimination pass'), integrating simple register allocation into it for the
common case of single-use instructions, etc. Another good way to speed up O0
codegen is to avoid generating as much horrible code in the frontend that the
optimizer (which isn't run at O0) is expected to clean up.
-Chris