[llvm-dev] Can LLVM emit machine code faster with no optimization passes?

[Jonas Maebe via llvm-dev]

On 12/10/16 20:32, Matthias Braun via llvm-dev wrote:
> But just as food for though: What if msvc did some minimal
> optimisations, found out that half the sourcecode is unreachable and
> removes it, while llvm with no optimisations just compiles everything?

llvm is actually extremely slow when it has to remove lots of dead code. 
I experienced that in the beginning when working on our llvm backend. I 
had some bugs in our code generator that caused about half of the llvm 
IR code to be dead, and compiling that code with -O1 made llvm extremely 
slow.

Another thing that makes llvm incredibly slow is loading/storing large 
aggregates directly (I know, now, that you're not supposed to do that). 
I guess it's the generation of the resulting spilling code that takes 
forever. See e.g. http://pastebin.com/krXhuEzF

All that said: we will also keep our original code generators in our 
compiler, and keep llvm as an option to optimise extra. In terms of 
speed, our code generators are much less complex and hence much faster 
than llvm's. We don't have instruction selection, but directly generate 
assembler via virtual methods of our parse tree node classes. That would 
be very hard to beat, even if things have gotten slower lately due to 
the addition of extra abstraction layers to support generating JVM 
bytecode and, yes, LLVM IR :)

There are also a few other reasons, but they're not relevant to this 
thread. (*)


Jonas

(*) We support several platforms that LLVM no longer supports and/or 
will probably never support (OS/2, 16 and 32 bit MS-DOS, Gameboy 
Advance, Amiga, Darwin/PowerPC), and the preference of some code 
generator/optimisation developers to write Pascal rather than C++ (our 
compiler is a self-hosted Pascal compiler)