LDTILECFG instruction (AMX-TILE, ACE, APX)

LDTILECFG reads a 64-byte block that selects a palette and, for palette 1, gives the shape of every tile:

Bytes	Field
0	palette: 0 releases the tiles, 1 is AMX, 2 is ACE
1	start_row, used to resume an interrupted tile load or store; normally 0
2-15	reserved, zero
16-31	bytes per row of tiles 0 to 7, two bytes each
32-47	reserved, zero
48-55	rows of tiles 0 to 7, one byte each
56-63	reserved, zero

Unused tiles must have zero in both fields. A palette the processor does not support, a shape beyond its limits or a nonzero reserved byte raises #GP. Loading a configuration also clears all tile data, so a program configures once and then works with the tiles; ACE’s palette 2 has fixed tile shapes and uses only byte 0. STTILECFG writes the current configuration back in the same format.

In the optimization guide

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

Golden Cove and Raptor Cove

Vectors, AVX-512 and AMX: On Sapphire and Emerald Rapids, a tile multiplication (tdp*) can start every 16 cycles and takes 52; a tile load every 8, taking 45; and loading the tile configuration takes about 204 cycles, worth doing once rather than in every call.

Forms

Every encoding of LDTILECFG that Intel XED knows, one row per XED instruction form (iform). How to read the notation.

Instruction	Encoding	Requires
`LDTILECFG m512` 64-bit mode only LDTILECFG_MEM	`VEX.128.NP.0F38.W0 49 /0`	ACE v1 or AMX_TILE
`LDTILECFG m512` LDTILECFG_MEM_APX	`EVEX.128.NP.0F38.W0 49 /0`	ACE v1 or APX_F + AMX_TILE

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.

Model	`m512`
Sapphire Rapids	100 / 0.25p0156

Operation

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

on = xcr0 if cr4 >> 18 & 1 else 0    # XCR0, where CR4.OSXSAVE is set
if on >> 17 & 3 != 3:                # TILECFG and TILEDATA
    fault(UD)
v = mem.read()                       # the 64 bytes
p = v & 0xFF                         # the palette
if not palettes >> p & 1:            # one the processor has
    fault(GP, 0)
if p == 2 and not on >> 20 & 1:      # ACE's needs SCALEDATA too
    fault(GP, 0)
if p == 1:
    if v >> 16 & (1 << 112) - 1:     # bytes 2 to 15
        fault(GP, 0)
    if v >> 256 & (1 << 128) - 1:    # bytes 32 to 47
        fault(GP, 0)
    if v >> 448:                     # bytes 56 to 63
        fault(GP, 0)
    for n in range(8):
        c = v >> 128 + 16 * n & 0xFFFF   # colsb of tile n
        r = v >> 384 + 8 * n & 0xFF      # its rows
        if c > 64 or r > 16:
            fault(GP, 0)
        if (c == 0) != (r == 0):     # both or neither
            fault(GP, 0)
elif p == 2 and v >> 8:              # bytes 1 to 63
    fault(GP, 0)
# palette 0 checks nothing: any other bytes are ignored
for t in range(8):                   # TILEDATA's initial state
    tmm[t].write(0)
if palettes >> 2 & 1:                # with ACE, every scale 2^0
    for i in range(128):
        bsr0.b[i] = 0x7F
tilecfg = v if p else 0              # palette 1 loads start_row too;
                                     # ACE's pseudocode then sets it
                                     # to 0
# IA32_XFD does not stop it (no #NM)

Not run on a processor: none of these processors has AMX.

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.

Operand	Kind	Action
`LDTILECFG m512` 64-bit mode only
`m512`	explicit	read

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.

VEX forms: AMX-E1
EVEX forms: AMX-E1-EVEX

Attributes

What else XED records about the forms. How to read.

All forms: may abort a TSX transaction

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to LDTILECFG, 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.

Intrinsic	Compiles to
`_tile_loadconfig` `void _tile_loadconfig(const void *__config)`	`LDTILECFG m512` VEX.128 -mamx-tile

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 set CPUID Processors

ISA set	CPUID	Processors
`AMX_TILE_BASE` AMX-TILE ACE	ACE v1 `CPUID.(EAX=07H,ECX=1):ECX[11]` ACE `CPUID.(EAX=1DH,ECX=2):EAX[7:0] ≥ 1` ACE version or AMX_TILE `CPUID.(EAX=07H,ECX=0):EDX[24]` AMX_TILE	Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids
`APX_F_AMX_BASE` APX	ACE v1 `CPUID.(EAX=07H,ECX=1):ECX[11]` ACE `CPUID.(EAX=1DH,ECX=2):EAX[7:0] ≥ 1` ACE version or APX_F + AMX_TILE `CPUID.(EAX=07H,ECX=1):EDX[21]` APX_F `CPUID.(EAX=07H,ECX=0):EDX[24]` AMX_TILE	Diamond Rapids

AMX_TILE_BASE

ACE v1
CPUID.(EAX=07H,ECX=1):ECX[11] ACE
CPUID.(EAX=1DH,ECX=2):EAX[7:0] ≥ 1 ACE version

AMX_TILE
CPUID.(EAX=07H,ECX=0):EDX[24] AMX_TILE

Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids

APX_F_AMX_BASE

ACE v1
CPUID.(EAX=07H,ECX=1):ECX[11] ACE
CPUID.(EAX=1DH,ECX=2):EAX[7:0] ≥ 1 ACE version

APX_F + AMX_TILE
CPUID.(EAX=07H,ECX=1):EDX[21] APX_F
CPUID.(EAX=07H,ECX=0):EDX[24] AMX_TILE

LDTILECFG