How Thorium Applies AVX2 and SSE4.2 Flags to Chromium Builds

The Thorium project is a performance-focused fork of the Chromium web browser that achieves significant speed improvements by compiling the source code with CPU-specific instruction sets. This article provides a technical breakdown of how Thorium modifies Chromium's native build configuration to inject compiler flags like AVX2 and SSE4.2, alongside other aggressive optimizations such as O3, ThinLTO, and Profile-Guided Optimization (PGO), to create hardware-tailored browser distributions.

Understanding the Chromium Build System

To understand how Thorium applies optimizations, it is necessary to look at how standard Chromium is built. Chromium uses a meta-build system called GN (Generate Ninja), which outputs build files for the Ninja build system, and relies almost exclusively on the Clang/LLVM compiler toolchain.

By default, mainstream Chromium builds are compiled to support a wide range of legacy hardware. Google configures the standard build to target older instruction sets—typically baseline x86-64 with SSE3—so that a single binary can run on almost any computer made in the last fifteen years. Thorium bypasses this one-size-fits-all approach by modifying the GN configuration files to target modern processor architectures specifically.

Modifying BUILD.gn and Configuration Files

The core of Thorium’s optimization process happens inside the Chromium source tree before compilation begins. The project applies custom patches to Chromium's main compiler configuration file, located at build/config/compiler/BUILD.gn, as well as platform-specific .gni (GN import) files.

In a standard Chromium build, the BUILD.gn file defines arrays of compiler flags (cflags, cflags_c, cflags_cc) and linker flags (ldflags). Thorium alters these arrays by appending architecture-specific flags directly into the build scripts. Before generating the Ninja files, the developer also configures an args.gn file, which acts as the master switchboard for the build, enabling custom boolean variables that trigger the injection of the new flags.

Injecting SSE4.2 and AVX2 Flags

Thorium segments its releases based on CPU capabilities, primarily focusing on SSE4.2, AVX, and AVX2. To create these specific builds, the project passes target flags directly to the Clang compiler during the build generation phase.

For the SSE4.2 build, which targets older Intel Core (Nehalem to Ivy Bridge) and early AMD processors, Thorium appends the following flags to the compiler configuration:

  • -msse4.2: Enables the generation of SSE4.2 instructions, improving string and text processing.
  • -mpopcnt: Enables the population count instruction, which calculates the number of set bits in a machine word.

For the AVX2 build, which targets Intel Haswell (4th generation) and newer, as well as AMD Excavator and Zen architectures, Thorium injects a more aggressive set of flags:

  • -march=haswell (or direct instruction equivalents): Tells the compiler to generate code optimized for architectures supporting AVX2.
  • -mavx2: Enables 256-bit Advanced Vector Extensions, allowing the CPU to process twice as much data per clock cycle compared to 128-bit SSE instructions.
  • -mfma: Enables Fused Multiply-Add instructions, which speeds up complex mathematical calculations used in media decoding and WebGL rendering.
  • -mbmi and -mbmi2: Enables Bit Manipulation Instruction sets, which optimize bit-level operations heavily used in compression, cryptography, and JavaScript execution (V8 engine).
  • -mlzcnt: Enables the leading zero count instruction.

By injecting these flags, Clang automatically vectorizes loops in the C++ code of the Blink rendering engine and the V8 JavaScript engine, translating standard code into wider 128-bit or 256-bit SIMD (Single Instruction, Multiple Data) instructions.

Combining Instruction Sets with O3, ThinLTO, and PGO

Applying AVX2 or SSE4.2 flags alone only yields partial performance gains. Thorium maximizes the effectiveness of these instruction sets by pairing them with compiler-level execution optimizations inside the same BUILD.gn patches.

  1. Compiler Optimization Level (-O3): Standard Chromium compiles many of its components using -O2 (moderate optimization) or -Os (optimize for binary size) to keep the browser footprint small and prevent cache misses. Thorium overrides these defaults and forces -O3 across the codebase. This instructs Clang to prioritize execution speed above binary size, enabling aggressive loop unrolling and function inlining, which directly creates more opportunities for AVX2 and SSE4.2 vectorization.
  2. ThinLTO (Link-Time Optimization): Thorium passes -flto=thin to both the compiler and the LLD linker. While standard compilation optimizes code file-by-file, ThinLTO allows the compiler to analyze and optimize code across different modules during the linking phase. This ensures that the AVX2 and SSE4.2 optimizations are applied globally rather than locally.
  3. Profile-Guided Optimization (PGO): Thorium utilizes PGO by feeding real-world browser usage profiles back into the compiler. This tells Clang which areas of the code are executed most frequently ("hot paths"). Clang then uses this data to aggressively apply the -O3 and AVX2/SSE4.2 vectorization specifically to those high-traffic areas while leaving rarely used code compact.

Generating Separate Binary Distributions

Because hardware instruction sets are not backward-compatible, a binary compiled with -mavx2 will immediately crash with an "Illegal Instruction" error if executed on an older CPU that only supports SSE4.2.

To solve this without relying on runtime CPU dispatching (which adds overhead), the Thorium project runs entirely separate build pipelines. The source tree is configured with the SSE4.2 args.gn profile, compiled via Ninja, and packaged. The build directory is then cleaned or switched, reconfigured with the AVX2 args.gn profile, and compiled again from scratch. This results in distinct, hardware-specific installers, shifting the burden of hardware compatibility from the compiler's runtime checks to the end-user, who simply downloads the version matching their processor.