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

[Matthias Braun via llvm-dev]

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>