Extensions
Forms
1 (1 Legacy)
Data
Intel XED v2026.08.23

LOOP subtracts 1 from RCX and jumps to a short relative target, within -128 to +127 bytes of the next instruction, while the result is not 0. It is a counted loop in one instruction: load the count into RCX, and put LOOP at the bottom of the body. It changes no flag, which sets it apart from the DEC and JNZ it stands for. LOOPE and LOOPNE also stop the loop when ZF, as an earlier instruction left it, is 0 or 1.

Edges

  • A count of 0. LOOP decrements before it tests, so a loop entered with RCX = 0 wraps it to 2^64 - 1 and runs that many more times, as Zen 5 did in the case recorded here. A JRCXZ in front of the loop skips it for a zero count.
  • The counter’s size. It follows the address size, not the operand size: RCX in 64-bit mode, ECX with a 67 prefix. The 32-bit form writes ECX as any 32-bit write does, clearing bits 63:32; Zen 5 took RCX = 0x2037AC07_00000001 to 0 and left the loop.
  • The target. The new RIP is checked like any jump’s: a non-canonical target raises #GP.

In compiled code

Neither GCC 14 nor Clang 23 emits LOOP, at -O2 or at -Os: a loop that counts down ends with sub rdi, 1 and jne (GCC) or dec rdi and jne (Clang). AMD’s Zen 5 guide shows the cost. Its instruction table lists LOOP, LOOPE and LOOPNE as microcoded, while JRCXZ is a single macro-op; and the guide’s branch fusion joins a SUB or a DEC with the conditional branch after it into one macro-op (Section 2.9.3), so the usual pair travels through the processor as one.

Where it fits

LOOP’s one advantage is that the flags survive it. A loop that carries CF from one pass to the next, such as an ADC chain over the words of a long number, cannot use SUB or CMP to count, since both write CF; LOOP, like DEC with JNZ, leaves CF alone. It is also short, two bytes with its offset, for code where size matters more than speed.

In the optimization guide

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

Bulldozer to Excavator

  • Branches: LOOP takes 7 cycles, 8 in 64-bit mode, where a dec and a jnz take one each. sources differ

Forms

Every encoding of LOOP that Intel XED knows, one row per XED instruction form (iform). How to read the notation.
InstructionEncodingRequires
LOOP rel8 LOOP_RELBRbE2 cbBase instruction set

Latency and throughput

What the scheduling models of LLVM 23.1.2 give for each form, not measurements: latency / reciprocal throughput in cycles, the ports under them. A row is a model, or models that agree; a dash, a form that its processors lack. Memory forms: latency from the address, ports without the load and store units. Which processors each model covers.
Modelrel8
Sandy Bridge3 / 3p015
Haswell, Broadwell, Skylake, Skylake-SP, Ice Lake7 / 2p0156
Alder Lake, Sapphire Rapids3 / 2p0 p1 p5 p6 p11
Lunar Lake1 / 0.33p024
Bonnell18 / 9p01
Silvermont1 / 1IEC1
Piledriver1 / 1Branch EX1
Zen, Zen 21 / 0.5ALU0 ALU3
Zen 3, Zen 41 / 0.5ALU0 BRU1
Jaguar1 / 0.5ALU0 ALU1

Operation

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

w = OSIZE                        # the size of the target
if OSIZE == 16:                  # a 66 prefix
    if INTEL:
        w = 64                   # ignored: SDM
c = low(aCX - 1, ASIZE)          # RCX; ECX with a 67 prefix, bits 63:32
aCX = c                          # then cleared; no flag changes
if c != 0:
    t = low(rip + signed(rel), w)    # with 66 on AMD's, IP alone
    if not canonical(t):             # (APM, Zen 5)
        fault(GP, 0)
    rip = t

Run on AMD Zen 5 (EPYC 9645): 11 cases. Its branches for Intel's processors were not run: no Intel processor ran these forms.

Operands

What each form reads and writes, as Intel XED records it: the operands of its syntax, in order, and the implicit ones that the syntax does not name. How to read.
OperandKindAction
LOOP rel8
rel8explicitread
rCXimplicitread, write
rIPimplicitread, write

Flags

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

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.

CPUID requirements and processors of the XED ISA sets above. Alternatives are separated by “or”; processors follow XED’s chip model, whose AMD processors end with Zen 2, and the CPU data of this site for Zen 3 to Zen 6.
ISA setCPUIDProcessors
I86

No CPUID bit: part of the base instruction set.

Every x86-64 processor in XED’s model and Zen 3 to Zen 6

More General-purpose instructions

All 109 General-purpose instructions

Sources

  1. Intel XED v2026.08.23 (commit 0bcb6237345c): forms, encodings, operands, flags, exception classes, attributes, ISA sets, CPUID bits and chip model.
  2. The CPU data of x86-64.net: Zen 3 to Zen 6, from GCC’s -march feature sets and AMD’s Processor Programming References, which the page of each processor cites.
  3. LLVM 23.1.2's x86 scheduling models (commit 85ac56026243): the latency, reciprocal throughput and ports of each form, as llvm-mca reports them.
  4. Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026): Volume 2A, page 3-570 (LOOP/LOOPcc)
  5. AMD64 Architecture Programmer's Manual, Volume 3: General-Purpose and System Instructions (24594, rev. 3.39, October 2026)
  6. Software Optimization Guide for the AMD Zen5 Microarchitecture (58455, rev. 1.00, August 2024), Wayback Machine copy of AMD's ZIP

The tables are derived from Intel XED, Copyright Intel Corporation, licensed under the Apache License 2.0; x86-64.net converted and reformatted them. The timings come from LLVM's scheduling models, part of the LLVM Project, licensed under the Apache License 2.0 with LLVM Exceptions. The text is our own.