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

[Mehdi Amini via llvm-dev]

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>