Rust Toolchain Migration: Supercharging Build Times with LLD on Windows
Recently, driven by the need to slash compilation and linking times, I migrated the toolchain for my pet Rust project. Previously, the project relied on the battle-tested stable-x86_64-pc-windows-gnu toolchain using the legacy ld linker—a notorious bottleneck responsible for much of Rust's sluggish build reputation on Windows.
While the speed payoff of switching to the lld linker was immediate, the transition exposed a labyrinth of subtle, platform-specific hurdles on Windows. Before diving into the migration details, let’s quickly break down the anatomy of how Rust compiles code.
!Image description
Under the Hood: The Rust Compilation Pipeline
If you trace a Rust file from source text to binary, it moves through several sophisticated stages:
AST (Abstract Syntax Tree): rustc parses the source code into an AST, where macros are expanded.
HIR (High-Level Intermediate Representation): The AST translates into HIR. This is where Rust’s borrow checker flexes its muscles, enforcing memory safety and ownership rules.
MIR (Mid-Level Intermediate Representation): The HIR simplifies into MIR, marking the end of rustc's proprietary heavy lifting.
LLVM Optimization: The pipeline hands off to the LLVM infrastructure. MIR is translated into platform-agnostic bitcode, where LLVM applies State-Of-The-Art (SOTA) optimizations. (LLVM’s power is precisely why Apple, Google, and massive Linux/Windows ecosystems rely on it).
Code Generation & Linking: LLVM generates machine code for specific target architectures, after which linkers bundle system and third-party libraries into the final executable.
The Windows Toolchain Maze: GNU vs. GnuLLVM
While Rust packages essential LLVM components out of the box, target-specific concerns—like operating system interfaces, C calling conventions, and ABIs—are bound to external packages.
The GNU Target (stable-x86_64-pc-windows-gnu): Simply requires MinGW-W64-builds to complete the toolchain pipeline.
The GnuLLVM Target (stable-x86_64-pc-windows-gnullvm): Requires standalone LLVM and llvm-mingw.
Navigating llvm-mingw can be jarring due to the sheer volume of overlapping binaries. Essentially, stock LLVM builds provide target-agnostic components that aren't inherently tied to MSVC or GNU C conventions. llvm-mingw bridges this gap, translating raw machine code into standard MinGW-compatible formats that Windows can execute.
Lessons Learned from the Trenches
Taming Windows toolchains is famously painful. It's the primary reason many developers flee to environments like MSYS2 or Windows Subsystem for Linux (WSL). However, because my pet project is a GUI application, native Windows integration is a must, and WSL's graphical UI maturity still introduces friction for native desktop apps.
The Golden Rule: Infrastructure upgrades like compiler toolchains should always be treated with extreme caution. Rigorous staging and testing are non-negotiable—never perform radical toolchain experiments blindly in production environments.
Bonus: Alternative Paths to Speed
If you want to tap into lld's blazing speed without undergoing a full toolchain migration, you can adopt it simply by changing some settings of your projects. Modern alternatives are pushing the boundaries of link-time performance even further. If you are feeling adventurous, check out these next-gen linkers built by hard-core pioneers:
mold — A high-performance, modern linker designed to drastically reduce build times.
wild — An experimental, incredibly fast linker written in Rust.
Mentions
Rust Toolchain Migration: Supercharging Build Times with LLD on Windows Recently, driven by the need to slash compilation and linking times, I migrated the toolchain for my pet Rust project. Previously, the project relied on the battle-tested stable-x86_64-pc-windows-gnu toolchain using the legacy ld linker—a notorious bottleneck responsible for much of Rust's sluggish build reputation on Windows. While the speed payoff of switching to the lld linker was immediate, the transition exposed a labyrinth of subtle, platform-specific hurdles on Windows. Before diving into the migration details, let’s quickly break down the anatomy of how Rust compiles code. !Image description Under the Hood: The Rust Compilation Pipeline If you trace a Rust file from source text to binary, it moves through several sophisticated stages: AST (Abstract Syntax Tree): rustc parses the source code into an AST, where macros are expanded. HIR (High-Level Intermediate Representation): The AST translates into HIR. This is where Rust’s borrow checker flexes its muscles, enforcing memory safety and ownership rules. MIR (Mid-Level Intermediate Representation): The HIR simplifies into MIR, marking the end of rustc's proprietary heavy lifting. LLVM Optimization: The pipeline hands off to the LLVM infrastructure. MIR is translated into platform-agnostic bitcode, where LLVM applies State-Of-The-Art (SOTA) optimizations. (LLVM’s power is precisely why Apple, Google, and massive Linux/Windows ecosystems rely on it). Code Generation & Linking: LLVM generates machine code for specific target architectures, after which linkers bundle system and third-party libraries into the final executable. The Windows Toolchain Maze: GNU vs. GnuLLVM While Rust packages essential LLVM components out of the box, target-specific concerns—like operating system interfaces, C calling conventions, and ABIs—are bound to external packages. The GNU Target (stable-x86_64-pc-windows-gnu): Simply requires MinGW-W64-builds to complete the toolchain pipeline. The GnuLLVM Target (stable-x86_64-pc-windows-gnullvm): Requires standalone LLVM and llvm-mingw. Navigating llvm-mingw can be jarring due to the sheer volume of overlapping binaries. Essentially, stock LLVM builds provide target-agnostic components that aren't inherently tied to MSVC or GNU C conventions. llvm-mingw bridges this gap, translating raw machine code into standard MinGW-compatible formats that Windows can execute. Lessons Learned from the Trenches Taming Windows toolchains is famously painful. It's the primary reason many developers flee to environments like MSYS2 or Windows Subsystem for Linux (WSL). However, because my pet project is a GUI application, native Windows integration is a must, and WSL's graphical UI maturity still introduces friction for native desktop apps. The Golden Rule: Infrastructure upgrades like compiler toolchains should always be treated with extreme caution. Rigorous staging and testing are non-negotiable—never perform radical toolchain experiments blindly in production environments. Bonus: Alternative Paths to Speed If you want to tap into lld's blazing speed without undergoing a full toolchain migration, you can adopt it simply by changing some settings of your projects. Modern alternatives are pushing the boundaries of link-time performance even further. If you are feeling adventurous, check out these next-gen linkers built by hard-core pioneers: mold — A high-performance, modern linker designed to drastically reduce build times. wild — An experimental, incredibly fast linker written in Rust.
Wild linker version 0.11.0 released with Wasm support Wild version 0.11.0 is out. Wild is a fast linker for Linux and Wasm. That's right, Wasm is now a supported platform! The Wasm port is working reasonably well and has great performance. The Wasm port was largely done by lapla-cogito during GSoC 2026.There are of course still a few things to be done like debug info. Linker script support has advanced considerably. This is largely the work of vishruth-thimmaiah during GSoC 2026. Lots of work has also been done on the Mac port, which is now to the point where at least one of the maintainers is using it as their default linker for Rust on Mac. It's not yet stabilised and there's still plenty to be done. We've had some performance gains and losses that to some extent cancel each other out. Some performance was lost by adding proper COMDAT support. For Rust code, which is pretty light on COMDAT usage, the impact was around 1.5%. On the up-side, some OS-level tweaks were made that fixed performance issues when the output is on filesystems like EXT4. We also now cap the maximum threads at 32, which fixes scaling issues that we were hitting beyond that point due to contention on a per-inode cache lock in the Linux kernel. You can read the full release notes here: github.com/wild-linker/wild/releases/tag/0.11.0
Many interesting updates. - COMDAT section group support (PR #2727): This is a major addition that makes performance comparisons between lld/mold/wild much fairer. I blogged about this feature before. However, this feature slows down symbol resolution considerably. I believe the COMDAT winners are different among the three linkers in some corner cases: the differences should be acceptable in practice. - Host kernel/filesystem probing for I/O optimization. I feel this is rather unfortunate maskray.me - They now vendor lld-tests. On the feature front, it's sad to see the implementation of niche features that are virtually unused in GNU ld -- such as the LDEMULATION environment variable and --error-execstack. These original requests typically come from reporters who may not know which options are actually important (likely driven by LLM-generated linker comparisons). I've noticed a similar trend with mold a few years ago, where several options are implemented that you almost never need, even if you build every package in Gentoo Linux. Rui Ueyama likely would have rejected them back when he maintained lld/ELF.
@mgill25 Linker is actually a big part of the compile time. Wild-linker is designed speed that up by a lot. Especially if you were using lld. wild-linker/wild