llvm dev - Oct 2016 - Can LLVM emit machine code faster with no optimization passes?

Hello,

Recently Jonathan Blow posted a short screencast discussing build time of
his compiler with when no optimizations are run on the user's code.

Part 1: https://www.youtube.com/watch?v=HLk4eiGUic8
Part 2: https://www.youtube.com/watch?v=mIjGYbol0O4

He discusses what parts are taking the longest to compile, and the
ultimately shows this:
http://i.imgur.com/BkbKcJK.png
...which shows that emitting LLVM IR in memory and
LLVMTargetMachineEmitToFile is the bottleneck in his compiler toolchain.

In fact, it was significantly faster to emit C to disk and compile with
MSVC than to emit LLVM in memory and call LLVMTargetMachineEmitToFile.

His conclusion is that he will not depend on LLVM when his users compile
with optimizations off, instead directly emitting x86_64 machine code into
an object file.

Needless to say, this is duplicate effort. Is there any way the LLVM
project could speed things up when no optimizations are run?

As another compiler author (http://ziglang.org/), I want to compete with
Jon's speed without having to duplicate the effort that LLVM already solves.

Thanks for your time.
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/520a6075/attachment.html>

Hi,

This is hard to answer in the abstract. There are multiple knobs that impact
compile time (optimization level, using fast-isel, etc).
Ideally we’d have an example of C output and IR output so that we can reproduce
offline and profile what happens.

— 
Mehdi
> On Oct 12, 2016, at 8:15 AM, Andrew Kelley via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello,
> 
> Recently Jonathan Blow posted a short screencast discussing build time of
his compiler with when no optimizations are run on the user's code.
> 
> Part 1: https://www.youtube.com/watch?v=HLk4eiGUic8
<https://www.youtube.com/watch?v=HLk4eiGUic8>
> Part 2: https://www.youtube.com/watch?v=mIjGYbol0O4
<https://www.youtube.com/watch?v=mIjGYbol0O4>
> 
> He discusses what parts are taking the longest to compile, and the
ultimately shows this:
> http://i.imgur.com/BkbKcJK.png <http://i.imgur.com/BkbKcJK.png>
> ...which shows that emitting LLVM IR in memory and
LLVMTargetMachineEmitToFile is the bottleneck in his compiler toolchain.
> 
> In fact, it was significantly faster to emit C to disk and compile with
MSVC than to emit LLVM in memory and call LLVMTargetMachineEmitToFile.
> 
> His conclusion is that he will not depend on LLVM when his users compile
with optimizations off, instead directly emitting x86_64 machine code into an
object file.
> 
> Needless to say, this is duplicate effort. Is there any way the LLVM
project could speed things up when no optimizations are run?
> 
> As another compiler author (http://ziglang.org/
<http://ziglang.org/>), I want to compete with Jon's speed without
having to duplicate the effort that LLVM already solves.
> 
> Thanks for your time.
> Andrew
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/e33678a1/attachment.html>

I don't think this can be discussed in this generality. Without knowing how
llvm is invoked, what sort of optimisations msvc was running. So this would be
best investigated with a concrete .ll file (llvm is a nice infrastructure in
that it makes it easy to share .bc/.ll files to capture intermediate states of
the compiler) which you can try to push through clang, opt, or llc to see
whether it matches the speed of msvc. 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?

- Matthias
> On Oct 12, 2016, at 8:15 AM, Andrew Kelley via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello,
> 
> Recently Jonathan Blow posted a short screencast discussing build time of
his compiler with when no optimizations are run on the user's code.
> 
> Part 1: https://www.youtube.com/watch?v=HLk4eiGUic8
<https://www.youtube.com/watch?v=HLk4eiGUic8>
> Part 2: https://www.youtube.com/watch?v=mIjGYbol0O4
<https://www.youtube.com/watch?v=mIjGYbol0O4>
> 
> He discusses what parts are taking the longest to compile, and the
ultimately shows this:
> http://i.imgur.com/BkbKcJK.png <http://i.imgur.com/BkbKcJK.png>
> ...which shows that emitting LLVM IR in memory and
LLVMTargetMachineEmitToFile is the bottleneck in his compiler toolchain.
> 
> In fact, it was significantly faster to emit C to disk and compile with
MSVC than to emit LLVM in memory and call LLVMTargetMachineEmitToFile.
> 
> His conclusion is that he will not depend on LLVM when his users compile
with optimizations off, instead directly emitting x86_64 machine code into an
object file.
> 
> Needless to say, this is duplicate effort. Is there any way the LLVM
project could speed things up when no optimizations are run?
> 
> As another compiler author (http://ziglang.org/
<http://ziglang.org/>), I want to compete with Jon's speed without
having to duplicate the effort that LLVM already solves.
> 
> Thanks for your time.
> Andrew
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/0dfb8c55/attachment.html>

On 12 October 2016 at 19:32, Matthias Braun via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I don't think this can be discussed in this generality. Without knowing
how
> llvm is invoked, what sort of optimisations msvc was running. So this would
> be best investigated with a concrete .ll file (llvm is a nice
infrastructure
> in that it makes it easy to share .bc/.ll files to capture intermediate
> states of the compiler) which you can try to push through clang, opt, or
llc
> to see whether it matches the speed of msvc. 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?
Right, that's a possibility. It also depends if the (code) workload is
prone to heavy DCE, which could be the case here, but it is not
necessarily true for all cases.

Still, invoking a separate project on Windows, which has costly forks
and all the parsing and building internal representations should
pretty much even the odds.

What I took from this video is that LLVM JIT is still too slow for
some usages || we're not good at communicating how to make the JIT
faster.

It also goes back to the discussion that O1 destroys too much of the
debug information to be useful but O0 is too dumb to have a smart
debugging experience.

Maybe that's why people use LLVM's JIT at O0?

But I'm certainly not a JIT expert, so these are just vague ramblings
not backed by any facts... :)

cheers,
--renato

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)