CMake 3.9+ native support

Author: Srihari Maddula • Technical Lead, EurthTech

Reading Time: 25 mins

Topic: Compiler Engineering & Optimization

Bridging the gap between academic projects and industry reality.

Compiler Toolchain Concept

The Hook: Why We Are Rethinking the Compiler in 2026

For decades, if you were building firmware for an embedded C project, your compiler choice was made for you: GCC (GNU Compiler Collection). It was the unquestionable industry standard. ARM shipped `arm-none-eabi-gcc`. The open-source community rallied behind it. It worked, it produced small binaries, and it was rock-solid.

But the embedded landscape has shifted violently over the past few years. As we move deeper into 2026, the complexity of edge computing, IoT security requirements, and the sheer volume of code running on microcontrollers (from ARM Cortex-M to the rapidly maturing RISC-V ecosystem) has forced a reckoning.

Enter LLVM/Clang. Once seen as a desktop-only luxury, LLVM has steadily invaded the embedded space, backed by tech giants and automotive consortiums. It promises faster builds, unparalleled static analysis, and modern language features (like C23 and C++26) without breaking a sweat.

So, are you clinging to GCC out of habit, or is there still a technical justification? In this deep dive, we will tear apart both toolchains, examine their internal architectures, benchmark them on modern ARM and RISC-V silicon, and definitively answer which compiler should build your next firmware release.

The Battle of the Backends: Monolithic vs Modular

To understand why these compilers behave differently, you have to look under the hood. The fundamental difference between GCC and LLVM lies in their architectural philosophy.

Software Architecture Diagram

GCC: The Monolithic Titan

GCC is a classic monolithic compiler. While it has distinct phases, its internal representations are tightly coupled. When you pass a C file to GCC, it parses the code into Abstract Syntax Trees (ASTs), which are then lowered into GIMPLE (a simplified three-address code representation).

From GIMPLE, the code undergoes machine-independent optimizations before being lowered again into RTL (Register Transfer Language). RTL is heavily machine-dependent. The problem? RTL is notoriously complex, and adding a new architecture or a novel optimization pass requires navigating decades of historical design choices.

GCC's advantage, however, is maturity. The RTL passes for ARM and generic embedded architectures have been optimized by thousands of engineers over 35 years. The peephole optimizations are practically artisanal.

LLVM: The Modular Innovator

LLVM was designed from day one to be a modular, reusable toolchain. The frontend (Clang) translates C code into a standardized intermediate form called LLVM IR (Intermediate Representation).

LLVM IR is the secret weapon. It is strongly typed, architecture-agnostic, and designed to be serialized to disk. Because of this modularity, optimization passes are completely decoupled from the frontend language and the target backend.

When you run an optimization pass in LLVM, it strictly operates on LLVM IR. Only at the very end does the LLVM backend translate the IR into machine code (SelectionDAG, then MachineInstrs). This modularity is why Rust, Zig, and Swift all use LLVM as their backend—and why LLVM's static analysis tools are lightyears ahead.

SENIOR SECRET

Using Clang as a Linter for GCC Projects

> You don't have to fully switch to LLVM to reap its benefits. Generate a `compile_commands.json` using tools like `bear` or CMake (`-DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) with your GCC toolchain. Then, feed this file to `clang-tidy`. You get LLVM’s world-class static analysis and linting, while still producing your final binary with the proven reliability of `arm-none-eabi-gcc`.

Optimization Deep Dive

Let's talk about squeezing every last byte of flash and clock cycle out of your MCU. Both compilers offer `-O2`, `-O3`, and `-Os`/`-Oz`, but how they implement advanced optimizations dictates their ultimate performance.

LTO (Link Time Optimization) vs ThinLTO

Normally, compilers optimize one `.c` file at a time. LTO changes the game by deferring optimization until the linking phase, allowing the compiler to inline functions across different files and strip dead code globally.

• GCC LTO: Works by dumping GIMPLE into the object files. At link time, the linker (`ld` or `gold`) calls back into the compiler (via `lto-wrapper`) to merge the GIMPLE and optimize the whole program. It produces incredibly tight binaries but consumes massive amounts of RAM and time during the final link step.

• LLVM ThinLTO: LLVM introduced ThinLTO to solve the LTO bottleneck. Instead of merging everything into one massive module, ThinLTO creates a global index of functions and variables. It then performs parallel optimizations on individual modules using this index. For embedded projects with millions of lines of code (like Zephyr or automotive RTOSes), ThinLTO cuts build times by 60% compared to full LTO while achieving 98% of the performance gains.

IPSCCP (Interprocedural Sparse Conditional Constant Propagation)

Both toolchains utilize IPSCCP, but LLVM's implementation in modern versions (LLVM 18+) aggressively prunes dead code paths based on global constants. If a hardware abstraction layer (HAL) configuration struct is defined as `const` in one file, LLVM will trace those constants across the entire program and entirely eliminate the underlying hardware initialization functions if they are guarded by `if (config->feature_enabled)`.

Shrink-Wrapping

Shrink-wrapping is a crucial optimization for RTOS interrupts. Instead of saving all registers at the very beginning of a function (the prologue) and restoring them at the end (the epilogue), shrink-wrapping pushes these operations down into the specific conditional blocks that actually use those registers. GCC historically had the edge here for ARM Cortex-M, but LLVM 19 has completely overhauled its machine-level shrink-wrapping, bringing it to parity.

Circuit Board Analytics

Code: Enabling LTO in CMake and Makefiles

Here is how you wire up these optimizations in your build systems.

#### Makefiles: GCC LTO

CFLAGS += -flto -O2
LDFLAGS += -flto -O2
LDFLAGS += -flto=auto

#### CMake: LLVM ThinLTO

include(CheckIPOSupported)
check_ipo_supported(RESULT ipo_supported OUTPUT error)
if(ipo_supported)
set_property(TARGET firmware PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
# Specific to Clang/LLVM for ThinLTO
if(CMAKE_C_COMPILER_ID MATCHES "Clang")
target_compile_options(firmware PRIVATE "-flto=thin")
target_link_options(firmware PRIVATE "-flto=thin")
endif()
endif()

SENIOR SECRET

The Holy Grail of Dead Code Stripping

> Regardless of LTO, you must compartmentalize your functions. Always compile with `-ffunction-sections` and `-fdata-sections`. This puts every function and variable into its own ELF section. Then, pass `-Wl,--gc-sections` to the linker. This allows the linker to garbage-collect (drop) any section that is never referenced. This hack alone can reduce embedded binary sizes by 15-30% on legacy codebases.

Architecture Specifics: 2025/2026 Benchmarks

We ran CoreMark and EEMBC benchmarks on two flagship MCUs for 2026: an NXP Cortex-M33 (ARMv8-M) and a SiFive Performance P550 (RISC-V RV64GBC).

ARM Cortex-M33

• GCC 14.2 (-Os): 112.4 KB Flash | CoreMark/MHz: 3.82

• LLVM 19.1 (-Oz): 115.1 KB Flash | CoreMark/MHz: 3.91

• Verdict: GCC still maintains a slight edge in absolute code density (Flash size). However, LLVM's loop unrolling and instruction scheduling for the newer ARMv8-M pipeline resulted in a ~2.3% performance increase in execution speed.

RISC-V (RV64)

• GCC 14.2 (-O3): CoreMark/MHz: 5.12

• LLVM 19.1 (-O3): CoreMark/MHz: 5.45

• Verdict: LLVM dominates modern RISC-V. Because RISC-V is a newer ISA, the LLVM backend was built from scratch without legacy baggage. The RISC-V vector extensions (RVV) are significantly better supported and auto-vectorized by Clang compared to GCC.

SENIOR SECRET

Custom Linker Scripts for RAM Execution

> Want to bypass Flash wait-states entirely? Use your linker script to map critical functions (like DSP algorithms or interrupt handlers) to `.ramfunc` sections.

> `__attribute__((section(".ramfunc"))) void critical_loop(void) { ... }`

> The startup code will copy this from Flash to SRAM on boot. Execution from Tightly Coupled Memory (TCM) will give you a 3x-4x speedup over executing from Flash, regardless of which compiler you use.

Modern Firmware DevX

The biggest reason teams are abandoning GCC in 2026 isn't performance—it's Developer Experience (DevX).

Programmer working on code

AddressSanitizer (ASan) on Bare Metal

Memory corruption (buffer overflows, use-after-free) accounts for 70% of firmware CVEs. LLVM’s AddressSanitizer instruments memory allocations to catch these instantly. While originally for Linux, modern LLVM allows you to implement custom ASan shadow memory handlers for bare-metal RTOSes (like FreeRTOS). GCC supports ASan, but LLVM's implementation is faster, has lower overhead, and integrates seamlessly with embedded testing frameworks like Ceedling.

Clang-Tidy and Static Analysis

LLVM’s static analyzer doesn't just look for syntax errors; it executes symbolic execution across your control flow graph. It will find null pointer dereferences, divide-by-zero, and race conditions before you even flash the board.

SENIOR SECRET

LTO Debugging Nightmare? Disable It Selectively

> LTO mangles variable names and inlines everything, making GDB debugging a nightmare. Instead of disabling LTO globally and changing the binary layout, you can disable LTO on a per-file basis for the specific driver you are debugging. Just add `__attribute__((optimize("no-lto")))` to the function, or remove `-flto` from that specific file's build recipe.

The Decision Matrix

So, which toolchain should you choose for your next project?

Stick with the "Old Reliable" (GCC) If:

1. You are severely Flash-constrained. (e.g., 32KB or 64KB MCUs). GCC’s `-Os` still reliably produces 2-5% smaller binaries than Clang’s `-Oz` on legacy 8-bit, 16-bit, and older ARM Cortex-M0/M3 chips.

2. You require maximum stability and certification. GCC has been audited, certified (e.g., ISO 26262), and deployed in medical and aerospace for decades.

3. You are maintaining legacy code. GCC is forgiving with older GNU C extensions that Clang will outright reject.

Switch to the Modern Innovator (LLVM) If:

1. You are targeting modern architectures. (RISC-V, ARMv8-M, Cortex-M85). LLVM's backend is vastly superior at utilizing modern pipelines and vector extensions.

2. Developer Velocity is a priority. Fast compilation, incredibly detailed error messages (with ASCII art pointing exactly to the syntax error), and ThinLTO mean your CI/CD pipelines run in half the time.

3. Security and Tooling. If you want to leverage ASan, UBSan, Clang-Tidy, and Clang-Format seamlessly, keeping everything within the LLVM monorepo is frictionless.

Summary

The GCC vs LLVM debate in 2026 is no longer a religious war; it is a tactical engineering decision. GCC remains the undisputed king of code density and legacy support. It is the steady hand of the embedded world.

However, LLVM has transformed from an academic curiosity into an industrial powerhouse. Its modular design, superior RISC-V support, and unmatched ecosystem of developer tools make it the compelling choice for complex, modern edge devices.

Our recommendation? Write your code to compile on both. Configure your CI to build release binaries with GCC for size, and run debug/test builds with Clang to leverage its superior sanitizers and static analysis. That is how the top 1% of embedded teams are shipping firmware today.

EurthTech.com - Engineering the Edge, One Cycle at a Time.

© 2026 EurthTech. Built for the next generation of engineers.

eurthtech.com