IMUL

IMUL is the signed multiplication, in three shapes:

• One operand, imul rsi: rAX times the operand, with the whole product, twice as wide, in rDX:rAX (in AX for bytes). It is the only form that yields the upper half.
• Two operands, imul rax, rsi: the destination times the source, cut to the destination’s width.
• Three operands, imul rax, rdi, 100: a register or memory operand times an 8- or 32-bit immediate, sign-extended, into another register.

Only the one-operand shape exists for bytes.

Signed and unsigned#

The lower half of a product is the same whether the inputs count as signed or unsigned, so the cut-down forms serve both: GCC 14 and Clang 23 at -O2 compile a * b on unsigned long to imul rax, rsi. Only the upper half differs. For it, signed code uses the one-operand IMUL and unsigned code MUL, which has no other shape, or MULX from BMI2, which takes its registers freely and leaves the flags alone. Both compilers turn (unsigned __int128)a * b into MUL, and Clang into MULX when allowed BMI2; the signed version becomes a one-operand IMUL.

Overflow#

CF and OF are set together when the signed product does not fit in the destination; for the one-operand form, when the upper half is anything but the sign extension of the lower. __builtin_mul_overflow on two longs is therefore IMUL followed by seto. For unsigned operands those flags answer the wrong question, and both compilers use MUL instead, whose flags tell whether the upper half is nonzero.

Constants#

A multiplication by a constant may become an IMUL with an immediate or a few LEA, shift and add instructions: for x * 100, Clang emits imul rax, rdi, 100 and GCC two LEAs and a SAL. Division by a constant turns into a multiplication as well, keeping the high bits of the product (see DIV).

APX#

APX adds a form with a new destination register and two sources, forms that leave the flags unchanged (NF), and, for the immediate forms, ZU: with EVEX.ND set, a 16-bit result clears bits 63:16 of its register instead of keeping them.

In the optimization guide

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

Bulldozer to Excavator

• Integer execution: EX1’s pipelined multiplier takes 4 cycles for operands of up to 32 bits, starting one every 2 cycles, and 6 for 64-bit operands, starting one every 4; LLVM’s model agrees.

Golden Cove and Raptor Cove

• Integer execution: A MUL of 64 by 64 bits into RDX:RAX is two micro-ops: the low half on port 1 and the high half on port 5, four cycles in LLVM’s models against three for an IMUL that keeps only the low half.

Jaguar and Puma

• Integer execution: The pipelined multiplier takes 3 cycles for operands of up to 32 bits, one a cycle, and 6 for 64-bit ones, one every 4; a form that writes two registers, such as MUL, adds a cycle to both. sources differ

Sandy Bridge and Ivy Bridge

• Integer and vector execution: Separate multipliers serve general-purpose and vector registers: a general-purpose multiply runs on port 1 at a latency of 3 cycles, a vector one on port 0 at 5 cycles for any precision, and both run one operation a 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
• Out-of-order and in-order execution: On Silvermont the widening one-operand mul and imul come from microcode; use the two-operand imul where the high half is not needed.

Skylake to Cooper Lake

• Integer execution: A MUL of 64 by 64 bits into RDX:RAX is two micro-ops on ports 1 and 5 and takes four cycles in LLVM’s models, against three for an IMUL that keeps only the low half.

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.

Zen and Zen+

• Integer execution: One ALU multiplies, up to 64 by 64 bits in three cycles, pipelined; a multiplication with two destination registers delivers the second a cycle later and starts only every other cycle. sources differ

Zen 2

• Integer execution: One ALU multiplies, 64 by 64 bits in three cycles and pipelined; a multiplication that writes two registers delivers the second a cycle later and starts only every other cycle.

Zen 3

• Integer execution: Only ALU 1 multiplies, 64 by 64 bits in three cycles and pipelined; a multiplication that writes two registers delivers the second one a cycle later.

Zen 4

• Integer execution: Only one ALU multiplies, 64 by 64 bits in three cycles and pipelined; a multiplication that writes two registers delivers the second one a cycle later.

Zen 5

• Integer execution: Three ALUs multiply, 64 by 64 bits in three cycles; a multiplication that writes two registers delivers the second one a cycle later.

Forms

Latency and throughput

Operation

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

p = signed(rAX) * signed(src)    # AL, AX, EAX or RAX times the source,
                                 # signed: a product of 2 * OSIZE bits
if OSIZE == 8:
    ax = p                       # AH:AL
else:                            # EDX and EAX: bits 63:32 cleared
    rDX = p >> OSIZE             # the high half
    rAX = p                      # the low half
if not nf:                       # NF=1 (APX) leaves the flags as they were
    big = 1 << (OSIZE - 1)
    cf = of = not -big <= p < big    # the product does not fit in rAX
    sf = zf = af = pf = UNDEFINED

p = signed(dest) * signed(src)
if not nf:                       # NF=1 (APX) leaves the flags as they were
    big = 1 << (OSIZE - 1)
    cf = of = not -big <= p < big    # the product does not fit in dest
    sf = zf = af = pf = UNDEFINED
dest.write(p)                    # its low OSIZE bits: the rest is lost

p = signed(src) * signed(imm)    # imm8, imm16 or imm32 as encoded, signed
if not nf:                       # NF=1 (APX) leaves the flags as they were
    big = 1 << (OSIZE - 1)
    cf = of = not -big <= p < big    # the product does not fit in dest
    sf = zf = af = pf = UNDEFINED
dest.write(p)                    # its low OSIZE bits: the rest is lost;
                                 # a ZU form (APX) clears bits 63:OSIZE,
                                 # even for 16 bits

p = signed(src1) * signed(src2)
if not nf:                       # NF=1 leaves the flags as they were
    big = 1 << (OSIZE - 1)
    cf = of = not -big <= p < big    # the product does not fit in dest
    sf = zf = af = pf = UNDEFINED
dest.write(p)                    # its low OSIZE bits in the new
                                 # destination: bits 63:OSIZE cleared,
                                 # even for 16 bits

Operands

Flags

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

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 General-purpose instructions

• CDQ
• CDQE
• CLC
• CLD
• CLI
• CMC
• CMP
• CMPS
• CMPXCHG
• CMPXCHG8B
• CPUID
• CQO
• CWD
• CWDE
• DAA
• DAS
• DEC
• DIV
• ENTER
• IDIV
• IN
• INC
• INS
• INT
• INT1
• INT3
• INTO
• IRET
• Jcc
• JCXZ
• JECXZ
• JMP
• JRCXZ
• LDS
• LEA
• LEAVE
• LES
• LFS
• LGS
• LODS

All 109 General-purpose instructions

More APX instructions

• AND
• ANDN
• AOR
• AXOR
• BEXTR
• BLSI
• BLSMSK
• BLSR
• BZHI
• CCMPscc
• CFCMOVcc
• CMOVcc
• CMPccXADD
• CRC32
• CTESTscc
• DEC
• DIV
• ENQCMD
• ENQCMDS
• IDIV
• INC
• INVEPT
• INVPCID
• INVVPID
• JMPABS
• KMOVB
• KMOVD
• KMOVQ
• KMOVW
• LDTILECFG
• LZCNT
• MOVBE
• MOVDIR64B
• MOVDIRI
• MOVRS
• MUL
• MULX
• NEG
• NOT
• OR

All 88 APX instructions