x86-64.net
日本語

x86 intrinsics A–Z

Every x86 intrinsic of Clang that compiles to a single instruction covered here, sorted by operation, with the instruction it compiles to.

Clang 23.1.2 defines 7,575 x86 intrinsics. 6,916 of them compile to a single instruction of this reference and are listed below and on the instruction pages. 621 compile to several instructions or none, work on masks but compile to general-purpose instructions, or have no instruction of their own; 23 are left out because their doc comment and compiled code disagree; and 15 could not be compiled on their own.

The list is sorted by the operation in the name, so _mm_add_ps, _mm256_add_ps and _mm512_mask_add_ps stand together under A. Each name links to its row on the instruction page, which shows the intrinsic’s signature, the exact form it compiles to and the Clang options it needs. Where an intrinsic compiles to more than one instruction depending on its operands, such as an FMA whose accumulator is already in the destination register, all of them are listed. Below the list is how intrinsics are matched to instructions.

A

B

C

D

E

F

G

H

I

K

L

M

N

O

P

R

S

T

U

W

X

Z

Other

How intrinsics are matched

The intrinsics come from the x86 headers of Clang 23.1.2 (commit 85ac56026243), which are part of the LLVM Project and licensed under the Apache License 2.0 with LLVM Exceptions. For each one, the build:

  • reads its signature, the target features it needs and what its doc comment says about instructions (“This intrinsic corresponds to the VPDPBUSD instruction”);
  • compiles a call to it with the Clang of the same release, for its own target features, and decodes the machine code with Intel XED. Variants of the call put another operand in the destination register or in memory, add AVX to SSE intrinsics, which then compile to VEX forms, and, for an intrinsic that works on masks alone, build every mask from KADD (which, unlike AND, OR, XOR, NOT or a move, has no general-register form) instead of taking it as the call’s own argument, so the k register the calling convention otherwise hides stays in the code (for _mm512_kunpackw and the other KUNPCK intrinsics, which read only the low half of each mask, at that half width: from masks of the full width, Clang builds them from mask-to-vector conversions instead);
  • lists it on an instruction page only if the call compiles to exactly that one instruction, apart from the code that passes arguments and returns the result, including the stores of results that an intrinsic returns through pointers, such as the two masks of _mm512_2intersect_epi32.

Where Clang’s doc comment names an instruction, the compiled code must confirm it. It may compile to an instruction that does the same thing on the bits but claims another data type, such as VMOVAPS for a documented VMOVDQA; the intrinsic is then listed with the documented instruction. Where the comment names only the VEX form of an SSE instruction, as for _mm_insert_ps, the legacy form that the call compiles to without AVX confirms it too. A few doc comments name the wrong instruction; those that concern this reference were checked by hand, and the instruction page says what the comment gets wrong.

Left out are intrinsics that compile to several instructions or to none, those that only zero a register, those built from a constant in memory (such as an absolute value made from a sign mask), those that work on masks alone and still leave no real instruction (such as _cvtmask16_u32, a plain reinterpretation of the bits), those whose call needs two results and so always compiles to more than one instruction (such as _kortest_mask16_u8, which runs KORTESTW twice for its two flags), those that Clang documents as having no instruction of its own, and those whose doc comment and compiled code disagree. Forms depend on the compiler: another compiler, or the same one with other options, can pick an equivalent instruction.

Each call is compiled with Clang’s execution-domain pass turned off. In a whole program that pass may swap an instruction for one that does the same on the bits but claims another data type, such as PAND and ANDPS, to suit the code around it; a call compiled alone has no code around it, and the pass would pick the floating-point form even for integer intrinsics. The forms listed are therefore what Clang selects for each intrinsic’s own types: _mm_and_si128 is listed with PAND, though in our builds at -O2 Clang emits ANDPS for it where the result is only stored or returned, and PAND where integer arithmetic follows.

Sources

  1. The LLVM Project, whose Clang has the x86 intrinsic headers in clang/lib/Headers
  2. Intel XED, the X86 Encoder Decoder