Regular multiplication propagates carries — that's what makes it slow and what makes it multiplication. But a huge swath of cryptography and error-checking lives in GF(2ⁿ), the finite field where addition is XOR and there are no carries at all. Doing that on general-purpose ALUs is miserable: you'd loop 64 times, shifting and conditionally XORing. Intel added PCLMULQDQ (Westmere, 2010) and ARM added PMULL to fix this in one instruction.

What it actually does. Take two 64-bit inputs, treat each bit as a coefficient in GF(2), and multiply the polynomials. The result is 128 bits. No carries — every partial-product row is XORed instead of added. Silicon-wise, it's a Wallace-tree-like reduction network but with XOR gates where a normal multiplier has full adders. Cheaper per stage, and no carry-propagate at the end.

Where it earns its transistors.

• AES-GCM authentication (GHASH). GHASH is multiplication in GF(2¹²⁸). Pre-PCLMULQDQ, GHASH was often slower than the AES encryption itself. With it, GHASH drops to roughly 1 cycle per byte on Ice Lake — often faster than the ciphertext generation.
• CRC with arbitrary polynomials. Intel's own paper showed CRC32C going from ~5.5 cycles/byte (table-based Slice-by-8) to ~0.4 cycles/byte using PCLMULQDQ folding — about 13× faster.
• Reed-Solomon erasure coding (Ceph, Backblaze-style storage).
• Elliptic curves over binary fields (sect233k1, etc.).

Rule of thumb. On modern Intel (Ice Lake+) and AMD Zen 3+, VPCLMULQDQ (the AVX-512 version) is fully pipelined at 1 op/cycle with ~5-cycle latency, processing four 64×64 multiplies per instruction. That's ~32 GB/s of GHASH throughput per core at 4 GHz. Compare with the software loop: 64 shift-and-XOR iterations per 64 bits, so roughly 64× slower. This is why TLS 1.3 handshakes on modern hardware are essentially free — the auth tag stopped mattering.

The catch. The instruction is picky: you specify which halves of the two source registers to multiply via an immediate byte (0x00, 0x01, 0x10, 0x11). To multiply two full 128-bit polynomials you need four PCLMULQDQs plus XORs — the classic "Karatsuba trick" cuts this to three, and every real GHASH implementation uses it.

A concrete win. OpenSSL's AES-128-GCM benchmark on a Xeon 8380: ~1.1 GB/s per core using generic C for GHASH, ~7.5 GB/s with PCLMULQDQ. Same AES core, same everything else — just the polynomial multiply changed.