LLVM 21 improvements for Qualcomm’s platforms

At Qualcomm Technologies, we maintain several compiler toolchains to allow our teams and customers to productize their code for our platforms. All our toolchains are based on LLVM, and we try to contribute as many of our changes and improvements to the LLVM open source project as possible.

Contributing our changes back to LLVM enables our improvements to be picked up by other LLVM-based projects, including the official Android toolchain.

The latest major release of LLVM is 21.1, released on August 26 2025, and our toolchain teams have made significant open-source contributions to this release in several areas. Team's contributions are made in collaboration with the upstream community, which we look forward to continuing.

RISC-V

Our RISC-V engineers have been contributing to LLVM 21 in two main areas:

• adding support for Qualcomm Technologies’ custom RISC-V extensions, Xqci and Xqccmp; and
• making improvements to how RISC-V is handled in Clang’s Driver.

Qualcomm Custom RISC-V Extensions

In August 2024, Qualcomm Technologies released a public specification for Xqci, our custom microcontroller extension for RISC-V. This extension contains a lot of new instructions, for a variety of uses from simple bit manipulation instructions to memory accesses with wider offsets, and new branches and jumps.

Our team has been working with the Xqci architects since then to refine the instruction definitions and support them in LLVM. We implemented basic assembler support for 10 of the Xqci sub-extensions in LLVM 20 and finished the assembly support for Xqci in LLVM 21.

As part of this group of assembler improvements, we added support for RISC-V’s non-standard (vendor) relocation scheme. This scheme annotates each non-standard relocation code with an additional `R_RISCV_VENDOR` relocation so that the linker can understand which vendor’s behavior to use when linking. We were the first vendor to adopt this scheme and implement it in LLVM’s assembler, and are pleased to see that Andes, another RISC-V vendor with their own extensions, has also adopted this scheme since we contributed the implementation.

Beyond assembly work, our focus in the LLVM 21 release has also been to implement code generation support for these extensions. For many sub-extensions, implementing this support means adding instruction selection patterns and code to make sure these patterns are used. This work has covered memory accesses, bit manipulation instructions, and arithmetic operations, as well as new ways of materializing larger immediate values.

In January 2025, Qualcomm Technologies followed-up the release of Xqci with the release of Xqccmp, a custom variant of the RISC-V Zcmp extension, altered to be compatible with the frame-pointer convention. We have also implemented both assembler and code-generation support for this extension in Clang/LLVM, ensuring these instructions will be used if the extension is available.

We also implemented support for new kinds of interrupt handlers in LLVM 21. This support allows users to write interrupt handlers in C/C++ rather than using assembly, as these handlers must save a larger set of registers than a conventional function. Beyond the existing machine and supervisor interrupt kinds, we have added two new interrupt handler kinds for the Xqciint extension (part of Xqci), which has specific interrupt entry and exit instructions to save registers on the stack. We also added support for SiFive’s Core Local Interrupt Controller (CLIC) scheme to LLVM, which we hope will aid RISC-V International’s Fast Interrupts Task Group’s work, as they work towards defining a specification.

It has been great to work with the community on implementing the recently-ratified Zilsd and Zclsd standard extensions, which allow loading and storing 64-bit values directly on 32-bit RISC-V systems, rather than 32-bits at a time.

Clang Driver Improvements

One major piece of technical debt in the Clang driver has been that there was a separate bare-metal toolchain definition for RISC-V than all the other bare-metal architectures. This toolchain definition is responsible for correctly invoking the relevant tools (compilers, linkers, archivers etc.) with the right arguments during a build, and differences here meant that RISC-V could not easily adopt improvements to the generic bare-metal toolchain.

Garvit Gupta, Engineer at QUALCOMM India Private Limited, over a large patch series, has aligned how the generic bare-metal toolchain definition works so that it can be used for RISC-V, without changing how it works for other targets. This has allowed us to remove the RISC-V specific toolchain definition, in favor of the generic version.

AArch64

The focus of our contributions to LLVM for AArch64 this release cycle has been enabling SVE (the Scalable Vector Extension) support for Windows. This work has been made up of several pieces.

• One piece of this work has been enabling SVE intrinsics. These allow users to write vector code in C, rather than having to use inline assembly, which should be easier to maintain and may allow the compiler to perform minor optimizations to the code. SVE Intrinsics are not yet supported by MSVC, Microsoft’s C++ Toolchain, but are supported by both GCC and Clang and are widely used for writing high-performance SVE programs.
  
  
• Another piece of this work has been enabling the SVE auto-vectorizer which allows the compiler to turn existing scalar loops into loops that use SVE instructions.

Underlying both pieces of work, we have been working with Microsoft to document and implement details of the MSVC ABI for these features. This has included ensuring that LLVM correctly implements the Windows calling convention; that Clang correctly mangles SVE type names when using C++; and that LLVM emits the correct C++ unwinding information for functions that use SVE.

The final key piece is to generate the right debug information on Windows, so that users can understand their code.

Hexagon NPU Architecture

We have also been making improvements for the Qualcomm Hexagon NPU architecture.

Disassembler Support in LLVM Objdump

Previously, we had significant downstream changes to support disassembling Hexagon’s VLIW packets.

Adarsha Regmi, Senior Engineer at Qualcomm Innovation Center, Inc., recently submitted these changes upstream so that LLVM can support instruction bundles (the LLVM term for a VLIW packet). This effort aligns with the rest of the LLVM objdump improvements for Hexagon.

Adarsha also implemented support for correctly diassembling and annotating PLT entries and symbols in LLVM objdump, which should make it easier to understand and debug linked binaries.

Clang

In addition to the changes to the Clang Driver and to SVE Support on Windows mentioned above, we have been contributing in a few other key areas to Clang.

Eli Friedman has been elected to the small group of Clang maintainers (known as the “Clang Area Team”). This team’s work so far has focused on reviewing community RFCs (Requests for Comments) and providing implementation guidance for new features.

The team is still getting established, but good progress is being made to ensure contributing major and/or controversial features to clang can proceed with such a large community.

We have continued to make minor fixes to Arm64EC, the WindowsABI used for applications that operate in the same process as legacy x86-64 libraries and programs. This ABI is crucial as it allows teams to adopt it without rebuilding their entire ecosystem.

Lastly, we have also been working on forward-looking features for C++23, including improving constant evaluation support, so that more functions can adopt constexpr in more situations.

LLDB

On the LLDB side, we have made two related contributions to support the package of work we did for LLVM 20 to make it easy to support proprietary or custom RISC-V instructions without modifying LLVM.

The first of these changes is to align LLDB’s disassembler with LLVM’s objdump so that it can show the raw encoding of instructions alongside their disassembly, as well as showing unknown instructions as “<unknown>”.

The second of these changes is to implement support for custom disassembler processes, so that LLDB can use an external program such as crustfilt to disassemble instructions as well as the built-in disassembler. This makes it easier for users to understand programs containing proprietary instructions, without having to juggle both a debugger and a separate disassembler.

What’s next?

Qualcomm Technologies is grateful to our collaborators across the LLVM project, and our toolchain engineers are continuing to make contributions and improvements for LLVM’s next major release, LLVM 22.1, due early in 2026.

We encourage you to adopt an LLVM 21-based toolchain for Qualcomm Technologies platforms to take advantage of these new features and improvements.

Join us on Developer Discord to contribute to real-time conversation on open source.

Further Reading

Detailed release notes are available for both LLVM 21 and Clang 21. The specifications for our RISC-V Custom Extensions are also available, for both Xqci and Xqccmp. The crustfilt tool is also available on github.