6 ms·

What's replacing LLVM? I didn't think LLVM was a problem, rather a necessary dependency to get all the optimization benefits, etc.

by speps 3y ago

pbaam 3y ago
They want to replace LLVM with their own backends. Zig's master branch can now be compiled without LLVM (and without CMake, see bootstrap.c) in x86 Linux because they implemented their own ELF linker and x86 code generation. It's explained in the talk why they want it: Most of the compile time is spent in LLVM, not in AST lowering or semantic analysis. Andrew also said that LLVM's coroutines weren't good enough to implement async/await.
- MaxBarraclough 3y ago
  (Discussion of the LLVM-free compiler begins at 10:30 in the video.) As someone who hasn't been following this: improved compile-times seem achievable, but they surely can't hope to compete with LLVM in terms of opimisation, can they? Is the new backend intended to be used for quicker dev builds, or for final release builds too? From a look here [0] it seems to be the latter - full removal of LLVM for all builds - which surprises me. [0] https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270
  - Laremere 3y ago
    It's a full removal of LLVM code being linked into the compiler. Currently Zig calls LLVM's API to build with it. Instead the compiler will gain the ability to emit LLVM IR into files. Those files can be passed to a separate install of LLVM to produce final machine code. As for the new backend vs LLVM, the new can be used for everything if it meets your needs. Initially LLVM is going to produce more optimized builds than Zig by itself can, but that is likely to change over time. LLVM isn't some magical blessing from the heavens, it's just software made by people. There's nothing besides effort and competence preventing another compiler matching its optimization performance. Plus, while a lot of research effort has been put into finding LLVM's optimizations, they've been found and can be copied.
    - tialaramex 3y ago
      There is however no reason to imagine you can get similar optimizations yet go much faster. Some of the optimization problems are just plain hard, indeed the optimal choices are often Undecidable for non-trivial cases, so LLVM is already trading time for better results. I have other reasons not to like LLVM, but I don't like the habit of blaming LLVM for how slow your compiler is, and Zig isn't alone in doing that. The segue into optimisation was Andrew noting that there are too many bugs. I haven't seen Andrew speak often before, so maybe it was a joke I didn't get, but the impression I got reminded me of Herb Sutter's introduction of Cpp2 / CppFront his "New syntax" (a C++ successor language by another name). Herb gives genuine complaints people have about C++ but rather than explain why his proposal would fix them (it wouldn't) he just decides they're wrong and rewrites them, then explains how his proposal fixes these made up complaints instead. So instead of "It's much too unsafe" Herb decides the "real" problem is that it's not easy enough to write - see if it was easier you wouldn't have bugs right? An audience members even calls him out for that, but Herb is undeterred. Like I said, maybe it's just a joke and I didn't get it. But if Andrew seriously thinks that: Zig has too many bugs => Make compiler faster makes any sense that's a problem.
      - mlugg 3y ago
        Hi, core team member here (I'm quoted in a parent comment!). The problem with LLVM is not that optimization is slow - it's perfectly acceptable for release builds to take arbitrarily long for optimal binaries. The problem is how long it takes to emit debug builds. Take building the Zig compiler itself in Debug mode. This process takes about 30 seconds running through the Zig pipeline (semantic analysis and generating LLVM IR), and then 90 seconds just spent waiting for LLVM to emit the binary. OTOH, when using our self-hosted x86_64 backend (which is now capable of building the compiler, although is incomplete enough that it's not necessarily integrated into our development cycle quite yet), that 30 seconds is essentially the full build (there are a couple of extra seconds on the end flushing the ELF file). I can tell you from first-hand experience that when fixing bugs, a huge amount of time is wasted just waiting for the compiler to build - lots of bugs can be solved with relative ease, but we need to test our fixes! Rebuilds are also made more common by the fact that LLVM has an unfortunate habit of butchering the debug information for some values even in debug builds, so we often have to rebuild with debug prints added to understand a problem. Making rebuilds 75% faster by just ditching LLVM would make a huge difference. Introducing incremental compilation (which we're actively working on) would make these rebuilds under a second, which would improve workflows a crazy amount. This would hugely increase our development velocity wrt both bugfixes and proposal implementation. It's also important to note that we have quite a few compiler bugs which are [caused by upstream LLVM bugs](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+llvm+label%3Aupstream https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...). LLVM often ships with regressions which we report before releases come out and they simply don't fix. In the long term, eliminating the use of LLVM as our main code generation backend will mean that all bugs encountered are our own, and thus can be solved more easily.
  - pbaam 3y ago
    > but they surely can't hope to compete with LLVM in terms of opimisation, can they? This has been discussed more than once on Zig's discord server. Quoting Andrew and Matthew Lugg's discussion in #compiler-devel about pull 17892: > mlugg: Shout-out to the people on Twitter and HN who are probably still saying "why would you try to compete with LLVM, LLVM is perfect and can do no wrong" > andrewrk: worse, they're saying "LLVM is not great but it's the best mankind can achieve" I think it's very appealing to have a project that focuses on fast build times and wants to seriously compete against LLVM in terms of the optimization pass pipeline, specially when you don't have a beefy computer. With that said, for the time being there are no optimizations made by Zig's own x86 backend (it neither does pass all behavior tests like it was pointed out in the talk, but it can build the Zig compiler itself and some other projects). Cuik[1] is a project that was mentioned in the Q&A section which illustrates how a compiler can be fast and make optimised builds at the same time. [1] https://github.com/RealNeGate/Cuik https://github.com/RealNeGate/Cuik
flohofwoe 3y ago
A mix of own code and the Clang toolchain moved into an optional package. As far as I understand it, the ability to optimize via LLVM and compile C++ and ObjC code via Clang won't be lost, just moved out of the Zig compiler into a package, integrated via the build system. The ability to import C headers and compile C code will remain in the core compiler though.
jenadine 3y ago
> What's replacing LLVM? AI? Just a LLM that convert Zig to optimized binary? /s

What's replacing LLVM? I didn't think LLVM was a problem, rather a necessary dependency to get all the optimization benefits, etc.

by speps 3y ago

What's replacing LLVM? I didn't think LLVM was a problem, rather a necessary dependency to get all the optimization benefits, etc.

pbaam 3y ago

They want to replace LLVM with their own backends. Zig's master branch can now be compiled without LLVM (and without CMake, see bootstrap.c) in x86 Linux because they implemented their own ELF linker and x86 code generation. It's explained in the talk why they want it: Most of the compile time is spent in LLVM, not in AST lowering or semantic analysis. Andrew also said that LLVM's coroutines weren't good enough to implement async/await.

MaxBarraclough 3y ago
(Discussion of the LLVM-free compiler begins at 10:30 in the video.) As someone who hasn't been following this: improved compile-times seem achievable, but they surely can't hope to compete with LLVM in terms of opimisation, can they? Is the new backend intended to be used for quicker dev builds, or for final release builds too? From a look here [0] it seems to be the latter - full removal of LLVM for all builds - which surprises me. [0] https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270
- Laremere 3y ago
  It's a full removal of LLVM code being linked into the compiler. Currently Zig calls LLVM's API to build with it. Instead the compiler will gain the ability to emit LLVM IR into files. Those files can be passed to a separate install of LLVM to produce final machine code. As for the new backend vs LLVM, the new can be used for everything if it meets your needs. Initially LLVM is going to produce more optimized builds than Zig by itself can, but that is likely to change over time. LLVM isn't some magical blessing from the heavens, it's just software made by people. There's nothing besides effort and competence preventing another compiler matching its optimization performance. Plus, while a lot of research effort has been put into finding LLVM's optimizations, they've been found and can be copied.
  - tialaramex 3y ago
    There is however no reason to imagine you can get similar optimizations yet go much faster. Some of the optimization problems are just plain hard, indeed the optimal choices are often Undecidable for non-trivial cases, so LLVM is already trading time for better results. I have other reasons not to like LLVM, but I don't like the habit of blaming LLVM for how slow your compiler is, and Zig isn't alone in doing that. The segue into optimisation was Andrew noting that there are too many bugs. I haven't seen Andrew speak often before, so maybe it was a joke I didn't get, but the impression I got reminded me of Herb Sutter's introduction of Cpp2 / CppFront his "New syntax" (a C++ successor language by another name). Herb gives genuine complaints people have about C++ but rather than explain why his proposal would fix them (it wouldn't) he just decides they're wrong and rewrites them, then explains how his proposal fixes these made up complaints instead. So instead of "It's much too unsafe" Herb decides the "real" problem is that it's not easy enough to write - see if it was easier you wouldn't have bugs right? An audience members even calls him out for that, but Herb is undeterred. Like I said, maybe it's just a joke and I didn't get it. But if Andrew seriously thinks that: Zig has too many bugs => Make compiler faster makes any sense that's a problem.
    - mlugg 3y ago
      Hi, core team member here (I'm quoted in a parent comment!). The problem with LLVM is not that optimization is slow - it's perfectly acceptable for release builds to take arbitrarily long for optimal binaries. The problem is how long it takes to emit debug builds. Take building the Zig compiler itself in Debug mode. This process takes about 30 seconds running through the Zig pipeline (semantic analysis and generating LLVM IR), and then 90 seconds just spent waiting for LLVM to emit the binary. OTOH, when using our self-hosted x86_64 backend (which is now capable of building the compiler, although is incomplete enough that it's not necessarily integrated into our development cycle quite yet), that 30 seconds is essentially the full build (there are a couple of extra seconds on the end flushing the ELF file). I can tell you from first-hand experience that when fixing bugs, a huge amount of time is wasted just waiting for the compiler to build - lots of bugs can be solved with relative ease, but we need to test our fixes! Rebuilds are also made more common by the fact that LLVM has an unfortunate habit of butchering the debug information for some values even in debug builds, so we often have to rebuild with debug prints added to understand a problem. Making rebuilds 75% faster by just ditching LLVM would make a huge difference. Introducing incremental compilation (which we're actively working on) would make these rebuilds under a second, which would improve workflows a crazy amount. This would hugely increase our development velocity wrt both bugfixes and proposal implementation. It's also important to note that we have quite a few compiler bugs which are [caused by upstream LLVM bugs](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+llvm+label%3Aupstream https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...). LLVM often ships with regressions which we report before releases come out and they simply don't fix. In the long term, eliminating the use of LLVM as our main code generation backend will mean that all bugs encountered are our own, and thus can be solved more easily.
- pbaam 3y ago
  > but they surely can't hope to compete with LLVM in terms of opimisation, can they? This has been discussed more than once on Zig's discord server. Quoting Andrew and Matthew Lugg's discussion in #compiler-devel about pull 17892: > mlugg: Shout-out to the people on Twitter and HN who are probably still saying "why would you try to compete with LLVM, LLVM is perfect and can do no wrong" > andrewrk: worse, they're saying "LLVM is not great but it's the best mankind can achieve" I think it's very appealing to have a project that focuses on fast build times and wants to seriously compete against LLVM in terms of the optimization pass pipeline, specially when you don't have a beefy computer. With that said, for the time being there are no optimizations made by Zig's own x86 backend (it neither does pass all behavior tests like it was pointed out in the talk, but it can build the Zig compiler itself and some other projects). Cuik[1] is a project that was mentioned in the Q&A section which illustrates how a compiler can be fast and make optimised builds at the same time. [1] https://github.com/RealNeGate/Cuik https://github.com/RealNeGate/Cuik

flohofwoe 3y ago

A mix of own code and the Clang toolchain moved into an optional package. As far as I understand it, the ability to optimize via LLVM and compile C++ and ObjC code via Clang won't be lost, just moved out of the Zig compiler into a package, integrated via the build system. The ability to import C headers and compile C code will remain in the core compiler though.

jenadine 3y ago

> What's replacing LLVM? AI? Just a LLM that convert Zig to optimized binary? /s