QBE 1.3 Delivers Windows Support and 33% Performance Gains in Compact Compiler Backend
QBE 1.3 Delivers Windows Support and 33% Performance Gains in Compact Compiler Backend
QBE 1.3 shipped today with Windows ABI support, position-independent code generation, and substantial performance improvements that bring the lightweight compiler backend to 63% of commercial compiler performance on the CoreMark benchmark. The release includes approximately 7,000 new lines of code and removes 1,500 lines, according to the official release notes.
The standout feature is native Windows compilation support contributed by Scott Graham, accessible through the -t amd64_win flag. This extends QBE's target coverage beyond its existing Linux, macOS, and bare-metal ARM64 and RISC-V support, addressing a significant deployment gap for developers building cross-platform toolchains around the SSA-based intermediate representation.
Performance and Optimization Advances
QBE 1.3 demonstrates a 33% performance improvement over version 1.2 when tested against the Hare programming language test suite. The release achieves more than 63% of commercial compiler performance on CoreMark, a meaningful milestone for a backend designed to deliver 70% of industrial compiler performance in 10% of the code size.
Roland Paterson-Jones contributed new optimizations that form part of this performance gain. The release also implements a new intermediate language matching algorithm using mgen, an OCaml-based code generation tool that appears to streamline pattern matching within QBE's uniform SSA representation.
These improvements matter in contexts where compilation speed and toolchain simplicity outweigh peak runtime performance. QBE compiles itself in two seconds on a Core 2 Duo with standard optimization flags—a design philosophy that prioritizes developer velocity over marginal runtime gains.
Shared Library and Position-Independent Code
The addition of position-independent code generation for shared objects represents a significant infrastructure capability. QBE 1.3 now supports indirect access to globals through the global offset table on ELF systems, enabling proper shared library construction across its supported Unix-like targets.
This functionality closes a critical gap for language implementers who need to generate shared libraries from QBE's intermediate representation. Combined with the existing C ABI compatibility and IEEE floating-point support, the backend now handles the full spectrum of modern library linkage patterns.
Windows ABI Integration
Scott Graham's Windows ABI implementation brings QBE into Microsoft's calling convention and object format ecosystem. The -t amd64_win target generates code compatible with the Windows x64 calling convention, handling stack alignment, parameter passing, and return value conventions that differ significantly from System V ABI used on Unix systems.
For cross-platform language runtimes and development tools, this Windows support eliminates the need for separate backend implementations or complex ABI translation layers. Language designers can now target QBE's uniform intermediate language and generate native code for all major desktop platforms.
Architecture and Design Philosophy
QBE operates as a deliberately constrained compiler backend, using the same SSA-based intermediate language at all compilation stages rather than the multi-tier intermediate representations common in larger compiler frameworks. This design choice trades some optimization potential for dramatically reduced implementation complexity.
The backend targets amd64 systems running Linux and macOS, ARM64 processors, and RISC-V64 architectures. Full C ABI support means existing C libraries integrate seamlessly with QBE-compiled code, while IEEE 32-bit and 64-bit floating-point support handles numerical computation requirements.
Looking at the broader compiler ecosystem, we have seen this pattern before with LLVM's emergence in the mid-2000s. While LLVM eventually grew into a comprehensive infrastructure project, its initial appeal lay in providing a clean intermediate representation that language implementers could target without building architecture-specific backends. QBE follows a similar philosophy but prioritizes compilation speed and implementation simplicity over LLVM's comprehensive optimization pipeline.
The 70% performance target reflects a pragmatic assessment of diminishing returns in compiler optimization. Many applications spend more time in I/O, memory access, or algorithmic bottlenecks than in tight computational loops where aggressive optimization delivers measurable gains. For rapid prototyping, educational use, or deployment scenarios where compilation time matters, QBE's approach offers compelling trade-offs.
Community and Development
QBE development occurs through a mailing list at ~mpu/qbe@lists.sr.ht, with real-time discussion on the #myrddin channel at irc.eigenstate.org. The project maintains a focused scope that enables individual contributors to make significant architectural contributions, as demonstrated by Graham's Windows ABI implementation and Paterson-Jones's optimization work.
The 7,000-line code addition alongside 1,500 lines removed suggests active refactoring and feature consolidation rather than simple feature accumulation. This maintenance approach aligns with QBE's core design goal of remaining a manageable codebase that individual developers can comprehend and modify.
The Windows support addition positions QBE as a viable backend for cross-platform programming language implementations that need native code generation without the complexity overhead of larger compiler infrastructures. Combined with the performance improvements and shared library support, version 1.3 represents a significant maturation of the platform's practical deployment capabilities.
