LLVM 24 Adds AMD AVX10_V2_AUX Support for FP8, FP6 and FP4

AMD's AVX10_V2_AUX Patch Lands in LLVM 24 Main​

Phoronix first reported the merge on September 23. It said the enablement landed "as of yesterday" in LLVM 24 Git and called it an important step toward the AI Compute Extensions (ACE). The code arrived through LLVM pull request #206888, titled "[clang] [compiler-rt] [llvm] [X86] AVX10_V2_AUX Implementation." Its author is AMD engineer Ganesh Gopalasubramanian, and the first patch in the series is dated July 1, 2026.

The work took about three months to go from first posting to merge. The LLVM commits mailing-list archive shows the pull request being updated on September 15, when the series stood at 15 patches. By merge time Phoronix counted about 15,000 lines of new code over 20 patches, which suggests the series grew during review. The title shows it touches three parts of the LLVM monorepo: the Clang front end, the LLVM core and X86 backend, and compiler-rt, the runtime-support library.

The public review thread shows how LLVM's X86 maintainers shaped the code before it went in. One reviewer seconded a suggestion that the AVX-512-style mask and zero-mask variants be written as wrappers around the base intrinsic, calling that approach "a lot easier to work with". Another comment pointed out missing memory folding. Memory folding lets the compiler merge a load from memory into the instruction that uses it. The merged series is the result of that back-and-forth.

LLVM's version numbering explains the timing. Clang's in-progress release notes describe the current main branch as release "24.0.0git", the development state of the next major version. LLVM ships its first stable build of each major version as x.1, so 24.1 is the first release most people will install. Phoronix puts it "around next March" and notes that other x86 Ecosystem Advisory Group work may also land before then. That date is a projection. LLVM has not announced a date.

Inside PR #206888: FP8, FP6 and FP4 Conversions for x86​

The patch description states the purpose in one line: AVX10_V2_AUX extends AVX10.2 with FP8/FP4/FP6 format conversions optimized for AI/ML inference workloads, enabling efficient low-precision arithmetic. Phoronix describes it as dedicated data processing and format conversion aimed at AI workloads. It covers converting standard data types into compressed formats like FP4 and FP6, more of the Open Compute Project (OCP) microscaling formats, and new rounding modes.

Some general background, which the sources don't spell out: AI inference increasingly stores model weights and activations in very narrow floating-point types, because smaller numbers mean less memory traffic and more values per vector register. The cost is conversion work. Data has to move between 32-bit single precision (FP32), where the arithmetic is often done, and 8-, 6- or 4-bit storage formats. AVX10_V2_AUX gives x86 dedicated instructions for those conversions. Doing it in software takes sequences of shifts, masks and rounding logic.

The patch groups the instructions into families:

Narrowing conversions from single-precision to FP8: VCVTPS2BF8, VCVTPS2HF8, VCVTPS2BF8S, VCVTPS2HF8S with optional saturation, biasing (VCVTBIASPS2BF8/HF8), and round-to-odd (VCVTROPS2HF8) variants make up the largest group. The builtin definitions in the patch also include a byte-unpack utility instruction, VUNPACKB, which takes an immediate operand. The builtins come in 128-, 256- and 512-bit vector widths.

The "BF8" and "HF8" names refer to two 8-bit floating-point layouts. In Intel's AVX10.2 naming these are generally understood as the E5M2 and E4M3 formats: five exponent bits with two mantissa bits, or four and three. That mapping is general context and isn't stated in the patch. The practical point is that the two layouts trade range against precision, and AI frameworks use both. Round-to-odd matters for accuracy when a value is converted in several steps, because it avoids the double-rounding error that can creep in.

How Clang 24 Exposes AVX10_V2_AUX: -mavx10v2aux, immintrin.h and Target Attributes​

For developers, the change shows up in three ways. First, per Phoronix, Clang takes a new -mavx10v2aux command-line flag to enable the extension for a whole translation unit. Inside the compiler, the patch registers a target feature named avx10-v2-aux, and Clang defines the preprocessor macro __AVX10_V2_AUX__ when the feature is on. That macro lets source code check at compile time whether the instructions are available.

Second, the intrinsics live in a new header, avx10_2_v2auxintrin.h. You don't include it directly. The header errors out unless it is pulled in through <immintrin.h>, the standard umbrella header for x86 intrinsics. The intrinsic names follow the familiar Intel pattern: _mm_cvtps_bf8 converts a 128-bit vector of floats to BF8, and _mm_mask_cvtps_bf8 is the masked version. The patch also adds CPUID definitions to Clang's cpuid.h, which programs use to query processor features.

Third, every intrinsic in the header carries the function attribute __target__("avx10-v2-aux"). So a developer doesn't have to compile a whole program with -mavx10v2aux. They can apply the feature to individual functions with Clang's target attribute. That is the standard way to build one binary that uses new instructions only in selected hot paths and keeps a baseline code path for older CPUs. Code built with the global flag will generally assume the instructions are present everywhere. Run it on a processor without them and it will typically crash with an illegal-instruction fault, so shipping software needs runtime CPU detection. The patch title includes compiler-rt, but the evidence doesn't document exactly which runtime-detection helpers were added there.

The patch also backs the instructions with an assembler and disassembler. Its tests cover AT&T and Intel syntax assembly for both 32-bit and 64-bit modes, plus disassembler tests verifying encoding and decoding. LLVM's assembler can accept hand-written AVX10_V2_AUX assembly, and tools built on LLVM's disassembler can decode binaries that contain the new opcodes. Anyone doing low-level work, such as reverse engineering, debugging, or checking compiler output, can now read these instructions instead of seeing unknown opcodes.

The intrinsics are the main path for now. The patch provides intrinsics and instruction selection for them. Nothing in the evidence says Clang's auto-vectorizer will turn ordinary C or C++ into these instructions on its own. Expect gains to come from libraries and runtimes written against the intrinsics, not from recompiling existing code with a new flag.

AVX10_V2_AUX Is One Piece of the Intel–AMD ACE Effort​

AVX10_V2_AUX belongs to ACE, the AI Compute Extensions that Intel and AMD are developing together through the x86 Ecosystem Advisory Group, the industry body the two companies formed to coordinate the direction of x86. Phoronix notes that engineers from both companies have worked on ACE software. The AVX10_V2_AUX compiler work appears to be AMD's part, and the LLVM patch is credited to an AMD engineer.

ACE and AVX10_V2_AUX are not the same thing. The ACE v1 specification treats AVX10_V2_AUX's OCP format conversions as one feature group. Integer VNNI (Vector Neural Network Instructions) operations and ACE tile instructions are separate groups. This merge gives LLVM the conversion part only. It doesn't mean LLVM now supports all of ACE, and more patches will be needed before the full specification is covered.

The specification also sets a higher bar for detecting full ACE v1 than for detecting this one extension. Its algorithm requires AVX10.1 plus either AVX10_V1_AUX or AVX10.2, along with AVX10_V2_AUX, the ACE feature itself, an ACE version of at least 1, and operating-system support for saving the relevant register state (AVX-512 state included) via XSAVE. That last condition is a reminder that new vector instructions need operating-system cooperation as well as a CPU and compiler. The kernel must save and restore the extended registers across context switches. That requirement applies to any OS running such hardware, but the evidence doesn't say how or when Windows or Linux will expose ACE.

GCC and LLVM Move on Separate Tracks​

AMD is enabling both major open-source compilers. In July 2026 it posted AVX10_V2_AUX patches for GCC. Phoronix described that series as seven patches covering CPUID detection, builtins and intrinsics. At the time they were proposals under review, and the evidence doesn't establish whether they have since been merged into GCC's development branch.

That leaves the two compilers at different stages. LLVM has merged its implementation for version 24. GCC's status after July is unconfirmed here. Projects that build with both, which is common in Linux packaging and cross-platform libraries, will need to check each toolchain separately before relying on the feature. The feature flag may be spelled the same way in both, but that doesn't mean both compilers ship it in the same release.

AMD's reason to push compiler support early is practical, even though it isn't documented. Compiler and assembler support has to exist, and usually has to be in stable releases, before library authors can build and test code paths for new instructions. Getting the patches upstream months before any stable release gives downstream projects time to prepare. The x86 vendors followed the same pattern with AVX10.2, which LLVM began merging back in the Clang 20 development cycle.

What this means for you​

Decide based on whether you write or ship code that handles low-precision AI data on x86. For almost everyone else, including Windows enthusiasts and administrators running packaged software, nothing changes today, and nothing needs to be enabled, patched or checked.

Developers of AI inference engines, math libraries and quantization tooling can start experimenting now by building Clang from LLVM main. Emulators and other tools that model x86 instruction sets are another route, if they support the extension, though the evidence doesn't identify any. Everyone else can wait for LLVM/Clang 24.1 or for their platform vendor to update its bundled Clang. The evidence doesn't say when Linux distributions, Apple, Microsoft's Visual Studio Clang integration or other downstream vendors will pick up LLVM 24, or whether any will backport the feature.

• AVX10_V2_AUX support was merged into LLVM 24's development branch on September 22, 2026, through pull request #206888, written by AMD's Ganesh Gopalasubramanian.
• Clang enables the extension with -mavx10v2aux, defines __AVX10_V2_AUX__ when it is active, and exposes the intrinsics through <immintrin.h> rather than a header you include directly.
• The instructions convert between FP32 and the FP8, FP6 and FP4 formats used in AI inference, with saturating, biased and round-to-odd variants in 128-, 256- and 512-bit widths.
• No stable compiler ships the feature yet, and Phoronix expects LLVM/Clang 24.1 around March 2027.
• The evidence names no processor that implements AVX10_V2_AUX and no benchmarks, so any code that uses it needs runtime CPU detection and a fallback path.
• AVX10_V2_AUX is only the format-conversion part of the Intel–AMD AI Compute Extensions, and the VNNI and tile instruction groups are separate.

The merge puts x86's AI format conversions into the mainstream open-source toolchain well before any stable release or confirmed hardware. For developers, that is exactly when upstream support is most useful. Watch for three things next: the LLVM/Clang 24.1 release expected next spring, the fate of AMD's parallel GCC series, and more ACE patches from the x86 Ecosystem Advisory Group for the VNNI and tile groups. The last of those will show whether open-source compilers support the full ACE specification by the time processors that implement it arrive.