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

Matthias Braun via llvm-dev
Wed, 12 Oct 2016 18:32:03 -0000

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>