TypeID Sentinel Address Table

An MLIR TypeID is the runtime identity tag MLIR uses for fast structural RTTI: every concrete C++ class the framework compares at runtime (a Dialect, an Op, a Type, an Attribute, an Interface, even a Trait) has exactly one mlir::TypeID value associated with it through mlir::TypeID::get<T>(). The implementation produces that value by reading the address of a per-class static storage object — the address itself is the identity. A typical compiled MLIR binary therefore contains hundreds of one-byte (or eight-byte Meyers-cached) anonymous globals in .bss / .rodata whose sole role is to be compared against each other by pointer equality. In tileiras (88 MB Blackwell-era CUDA 13.1 MLIR-based optimizing assembler) those sentinels cluster densely in the 0x5B37B90 .. 0x5BE6138 band of the static-data segment, and one sentinel address suffices to back-trace from a stripped function to the exact Op/Type/Attr class it dispatches on. This page is the canonical reverse-direction lookup table: address in, dialect-and-class out.

The binary uses two sentinel idioms in parallel. First, static pointer-identity sentinels: one-byte .bss slots whose address is the TypeID. No code ever writes the byte; the pointer is the value. These dominate the cute / cute_nvgpu / nv_tileas / NVVM op slabs. Second, Meyers-cached sentinels: an {8-bit guard, 64-bit qword} pair where the qword fills in on first use by interning a C++-mangled mlir::TypeID::getFullName() string through a process-wide pool (sub_44A6CA0 in this binary; upstream MLIR ships the same RTTI-string-to-pointer interner under llvm::ManagedStatic). After init, the qword holds the TypeID. These dominate the cute interface anchors and a few standalone singletons. Both forms reach the per-op dispatcher exactly the same way: through a load of *(qword*)(op + 48) + 16 (the OperationName::TypeID slot) and a pointer-equality test against a sentinel address baked into the dispatcher arm.

A third special case is the "shared no-properties guard" &unk_5BE6138 — the global OperationName::TypeID reserved for the sentinel class mlir::detail::UnregisteredOpProperties. Every NVVM-to-LLVM and TileAS layout-classifier dispatcher tests against it first to short-circuit the no-properties path or detect an op being mid-rewritten. Every arm references it, making it the single most-cited sentinel in the binary.

How sentinels are consumed at runtime

Pointer-identity and Meyers-cached sentinels reach the dispatcher through the same OperationName::TypeID slot; only the lazy-init step differs. The minimum-cost lookup that a reimplementation must reproduce is:

/* Pointer-identity sentinel — the address is the TypeID. */
const void *type_id_pointer_identity(const void *sentinel_byte_slot) {
    return sentinel_byte_slot;            /* no load; pointer is the value */
}

/* Meyers-cached sentinel — first call interns the C++ mangled
 * mlir::TypeID::getFullName() string through the process-wide pool
 * (sub_44A6CA0 in this binary), races resolved by the Itanium ABI
 * guard byte. After init, the qword holds the TypeID. */
const void *type_id_meyers_cached(uint8_t *guard, const void **qword,
                                  const char *type_full_name) {
    if (__atomic_load_n(guard, __ATOMIC_ACQUIRE) == 0) {
        if (__cxa_guard_acquire(guard)) {
            *qword = intern_typeid_string(type_full_name);
            __cxa_guard_release(guard);
        }
    }
    return *qword;
}

/* Dispatch is pointer-equality on the resolved TypeID, applied against
 * the OperationName::TypeID slot reached through Operation+0x30 ->
 * OperationName::Impl+0x10. */
static inline bool op_is_sentinel(const void *op, const void *sentinel) {
    const void *opname_impl = *(const void *const *)((const uint8_t *)op + 0x30);
    const void *type_id     = *(const void *const *)((const uint8_t *)opname_impl + 0x10);
    return type_id == sentinel;
}

Allocating a fresh TypeID storage per call instead of through one static slot will produce one new identity per call site, which makes pointer-equality dispatch impossible. The address-band discipline below — every sentinel of a kind lives in one contiguous slab emitted by one translation unit — is what guarantees one address per kind.

Address-band index

The table partitions the sentinel space into the contiguous bands the linker emitted for each dialect / category. Numbers under "Count" are the distinct sentinels inside that band referenced elsewhere in the binary; the rest is padding.

The runtime invariant this layout captures: a sentinel address in 0x5B44E* / 0x5B44F* is an OperationName::opInfo slot (the descriptor passed at registration time), whereas one in 0x5BE3F* / 0x5BE4* / 0x5BE5* is the paired kindPtr slot (AbstractOperation::TypeID) that ends up in op->getName().getTypeID() after uniquing. The two ranges contain duplicates of each op identity at two different indirection levels; resolvers and rewriters generally compare against the kindPtr form, op-builders and registrars against the opInfo form.

Master sentinel table

Sorted by sentinel address, ascending. For each row: dialect, the C++ class or op/type/attr name, byte length of the sentinel's storage (1 for pointer-identity, 8 for the qword half of a Meyers pair, 9 for the guard+qword combined), and the wiki page that documents the matching op / type / interface in detail.

NVVM op TypeID slab close-up: 0x5B8D610 .. 0x5B8DCB8

The largest sentinel cluster in the binary is the contiguous NVVM-op slab at 0x5B8D610 .. 0x5B8DCB8. It is 1704 bytes long (0x6A8), holds 213 8-byte slots at uniform 8-byte stride, and the NVVMToLLVM lowering dispatcher (sub_2D67A80, 92 KB) tests 197 of those slots as per-op TypeID sentinels in a folded dyn_cast cascade walking the slab from top-of-range (0x5B8DCB8) down. The remaining 16 slots correspond to NVVM op classes handled exclusively by the SelectionDAG MatcherTable path (sub_1A833C0) and never appear as explicit dispatcher arms.

Why it is contiguous: the linker emits one mlir::TypeID::Storage-array initialization per dialect, where every op-class registered through the TableGen-generated registerNVVMDialect() entry point produces one 8-byte slot containing the address of the class's static thread_local TypeID::UniqueIdHolder. All 213 slots come from one translation unit's static data, so they land in a single .rodata section with no padding between slots — exactly the pattern observed.

How to read offset → op name: index i = (slab_address - 0x5B8D610) / 8. The dispatcher walks arms in slab-descending order, so the first arm reached at line ~2067 of sub_2D67A80 matches 0x5B8DCB8 (NVVM::CpAsyncCommitGroupOp). Each subsequent arm decrements the slot by 8. Slot 0x5B8D610 + 8*i for i ∈ [0, 212] therefore corresponds to the (212 - i)-th arm in walk order.

Selected anchor sentinels from inside the slab, with their op classes:

Block-anchor band assignments (within the slab, from the dispatcher walk order):

Slot stride and storage rationale: each slot is exactly 8 bytes because the slab stores raw void* pointers, and on x86-64 the AT&T psABI guarantees _Alignof(void*) == sizeof(void*) == 8. The address of slot i is 0x5B8D610 + 8*i, no per-slot padding. The dispatcher reads each sentinel address as an immediate operand baked into the per-arm cmp instruction, so any reimplementation must keep the slab contiguous and 8-byte aligned for the fold-up cascade to remain a single cmp/je chain.

The shared &unk_5BE6138 no-properties guard sits ~0x59 KB later than the slab, in a different translation unit. Upstream MLIR intends this: UnregisteredOpProperties::TypeID lives in mlir/IR/OperationSupport.cpp, separate from the dialect's generated registerNVVMDialect() translation unit. Placing the no-properties sentinel outside the slab guards against a pointer-equality false-positive when an arm tests op.getName().getTypeID() == &slab[i] against an op whose properties record was never built.

Cross-references

The companion table Op Mnemonic Master Table indexes the same sentinels by op-name rather than by address, with verbatim mnemonics, length bytes, and one-clause semantics for every registered op.

The Cross-references column in the master table points to the canonical wiki page for each sentinel's op or type. Conventions:

• dialects/<dialect>/<op-mnemonic>.md for op-info / op-class sentinels
• dialects/<dialect>/types.md for concrete Type TypeIDs
• dialects/<dialect>/interfaces.md for type-interface anchors (Meyers pairs)
• dialects/<dialect>/index.md for dialect-level TypeIDs and ranges whose per-op decomposition is documented separately
• dialects/index.md for upstream MLIR / cross-dialect anchors

Two cross-dialect sharing patterns are worth highlighting:

1. 0x5B49B18 is reused by both cute.ConstrainedInt and cute_nvgpu.AtomIType. The two share pointer identity because the inline printer emits the same i<N>(<divby M>)? surface syntax for both, and the underlying AbstractType class is parameterised on the same set of attributes — TableGen emits a single TypeID.
2. The PrintableTypeInterface qword 0x5B47028 is attached to every cute and almost every cute_nvgpu concrete type (27+ installs). When you trace a sentinel comparison against 0x5B47028, you are inside the PrintableTypeInterface dispatch, not a per-type check.

Pairing convention: nv_tileas.convert_layout exemplifies the two-form encoding. Its OperationName opInfo slot (the descriptor passed to sub_4461CA0 at op registration) is 0x5B44FD8, while its AbstractOperation::TypeID slot (the kindPtr reachable via *(qword*)(op+48)+16 after uniquing) is 0x5BE4008. Resolvers compare against the kindPtr; op-builders against the opInfo. Treat them as the same op identity at two different indirection levels.