CRC32

CRC32 folds 1, 2, 4 or 8 bytes of data into a running 32-bit checksum. Despite the name, the checksum is CRC-32C, with Castagnoli’s polynomial 0x1EDC6F41, not the CRC-32 whose polynomial is 0x04C11DB7: a format that uses the latter gains nothing from this instruction and needs another method, such as carry-less multiplication with PCLMULQDQ.

What it leaves to the program#

The instruction does the polynomial division and nothing else. CRC-32C as formats define it starts from all ones and inverts the final value, so code does both around its loop: crc = ~crc, one CRC32 per chunk of data, then ~crc. With them, the nine bytes “123456789” give 0xE3069283; without them, 0x58E3FA20.

The CRC lives in bits 31:0 of the destination. The 64-bit form reads 8 bytes per step, but its result is still 32 bits wide with bits 63:32 cleared, and the upper half of the incoming register does not count: Zen 5 gave 9F787F65H, the result from FFFFFFFFH, for the bytes “12345678” whether RCX held 32206E22FFFFFFFFH or BD8D94DAFFFFFFFFH. So _mm_crc32_u64 returns a 64-bit value whose upper half is zero, and a loop can feed it back as it is.

The data enters bit 0 first, and the CRC’s coefficients are stored in reverse, which is why the page’s pseudocode shifts right and uses 0x82F63B78, the polynomial with its bits reversed. AMD’s manual calls this reversal “inverting” the operands and the result; it means the order of the bits, not their values, and Zen 5’s results agree.

Compilers#

GCC 14 and Clang 23 at -O2 never turn a bitwise CRC-32C loop into CRC32, even with -msse4.2; Clang replaces the inner loop by a 256-entry table instead. The intrinsics are the way to the instruction: _mm_crc32_u8 in a byte loop becomes crc32 eax, byte ptr [rsi], which Clang unrolls eight times.

Speed#

Intel’s optimization manual uses CRC32 as a string hash and finds it about twice as fast as a multiply-and-add hash for short and medium strings (Section 14.1.1). In Zen 5, three of the six integer ALUs can compute CRCs (AMD’s Zen 5 guide, Section 2.10.2), and the guide’s instruction table lists CRC32 as one macro-op with a latency of three cycles.

CRC32 belongs to SSE4.2 and so to x86-64-v2; APX adds an EVEX form that reaches its new registers.

In the optimization guide

What the optimization guide says about CRC32, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Golden Cove and Raptor Cove

• Integer execution: Port 1 alone runs the slower integer operations: multiplication, PDEP and PEXT, popcnt, bsr, crc32 and the double shifts with an immediate count, which LLVM’s models give a latency of three cycles and one per cycle.

Silvermont to Goldmont Plus

• Out-of-order and in-order execution: On Silvermont shifts and rotates run on integer port 0, and jumps, multiplication, popcnt, crc32 and bit operations on port 1. sources differ
• Instruction set and counters: Silvermont is the first Atom core with SSE4.2 and POPCNT; Goldmont Plus adds RDPID and PTWRITE.

Tremont

• Integer execution: Three ALU ports run simple integer operations, three a cycle; shifts go to port 00 only, and multiplication, division, popcnt, crc32 and the bit operations to port 01 only.

Forms

Latency and throughput

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

crc = dest & 0xFFFFFFFF          # the CRC so far: bits 31:0, even of r64
crc ^= src.read()                # the data enters bit 0 first
for i in range(src.bits):
    if crc & 1:
        crc = crc >> 1 ^ 0x82F63B78  # Castagnoli's polynomial 1EDC6F41
    else:                            # with its bits reversed
        crc >>= 1
dest.write(crc)                  # bits 63:32 cleared, even of r64
# no inversion before or after: CRC-32C as software computes it
# starts from all ones and inverts the result

Operands

Flags

None: XED records no flag that the forms test or change.

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

Legacy forms

none in XED

EVEX forms

APX-EVEX-INT

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to CRC32, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More SSE4.2 instructions

• PCMPESTRI
• PCMPESTRM
• PCMPGTQ
• PCMPISTRI
• PCMPISTRM

More APX instructions

• AADD
• AAND
• ADC
• ADCX
• ADD
• ADOX
• AND
• ANDN
• AOR
• AXOR
• BEXTR
• BLSI
• BLSMSK
• BLSR
• BZHI
• CCMPscc
• CFCMOVcc
• CMOVcc
• CMPccXADD
• CTESTscc
• DEC
• DIV
• ENQCMD
• ENQCMDS
• IDIV
• IMUL
• INC
• INVEPT
• INVPCID
• INVVPID
• JMPABS
• KMOVB
• KMOVD
• KMOVQ
• KMOVW
• LDTILECFG
• LZCNT
• MOVBE
• MOVDIR64B
• MOVDIRI

All 88 APX instructions