Data Structure Layouts

All addresses in this page apply to ptxas v13.0.88 (CUDA 13.0). Other versions will differ.

This page documents the key internal data structures in ptxas v13.0.88: the compilation context ("god object"), the Ori Code Object, symbol tables, constant/shared memory descriptors, the pool allocator's object model, and the generic container types (hash maps, linked lists, growable arrays) that underpin nearly every subsystem.

All offsets are byte offsets from the structure base unless otherwise noted. Types are inferred from decompiled access patterns. Field names are reverse-engineered -- the binary is stripped.

Compilation Context (the "God Object")

The compilation context is the central state object passed to every phase in the pipeline. It is not the Code Object (which is per-function); it is the per-compilation-unit container that owns the Code Object, the knob system, the output stream, the function list, and all per-pass configuration. The sub_7FBB70 (PerKernelEntry) function receives this as a1, and every phase's execute() receives it as the second argument.

The context is a polymorphic C++ object with a vtable at offset +0. It is allocated by the compilation driver and persists for the lifetime of a single compilation unit. Key observations:

• The vtable at +0 provides 263+ virtual methods (vtable spans to offset 2104+)
• The object's struct size is 1832 bytes as recorded in *(ctx+1536) by the deep-clear routine sub_C1B7A0 (*(a1+1536) = 1832), but the constructor sub_7F7DC0 writes fields out to +2136, indicating the in-memory layout extends slightly past the nominal struct size for tail extension fields
• The knob/options system is accessed through an indirection at +1664 (pointer to knob container object)
• The output stream lives at +1440

The full constructor is sub_7F7DC0 (1270 lines). The map below was rebuilt by:

1. Reading every initialization line of sub_7F7DC0 (the canonical ctor) to nail down field types from initial values and accessor widths
2. Cross-referencing 29 phase-execute functions where a1 is provably the ctx (filtered by requiring both *(a1+1584) and *(a1+1664) accesses in the same file) and tallying offset access frequency with rg --no-filename --only-matching '\(a1 \+ \d{3,4}\)' | sort | uniq -c
3. For each top-frequency offset, opening the use sites to derive the semantic role from how the value is written, read, indexed, dispatched, and gated against

Compilation Context Field Map

The map is grouped by functional region rather than strict offset order, so that callers reading the cleanup code (which iterates by region) and callers reading dispatch code (which jumps between regions) can both find what they need.

Header / Lifetime / Allocator (+0..+96)

Embedded Hash-Map Containers, Bin 1 (+104..+200)

This bin holds three or four small hash-map / sorted-array containers. The allocator view at +16 is used to allocate their bucket arrays. Each container has the layout {header*, ptr, ptr, ptr, ptr, u32 count} packed across ~24-40 bytes.

Function Object Table (+208..+340)

The most-accessed structural region of the ctx. This is the function-id-indexed lookup table: given a function id, dereference *(a1+296) + 8*id to get the per-function Code Object pointer. The table is a growable inline array (the inline buffer immediately follows the metadata fields).

Function Name Table (+344..+416)

A second growable array, parallel to the function object table, storing per-function names.

Code Object Stage Buffers (+424..+712)

A bank of growable arrays each managed by the same {allocator, buffer, count, capacity} quad pattern. Used to hold per-stage transient data (intermediate results between consecutive passes).

Call-Graph / Traversal State (+736..+1008)

Linked Lists, Hash Maps, and Misc Containers (+1120..+1352)

Phase Bitfield Bank (+1368..+1421)

A 54-byte region of densely packed boolean / multi-bit gate flags. The constructor sub_7F7DC0 lines 686-872 initialize this region by reading individual fields from the option struct (a2) and packing them into bit positions. Some bytes (+1376, +1396, +1412, +1414, +1416, +1418) were partially documented before; the table below adds the missing ones and corrects the type widths.

Output Stream and Timing Records (+1440..+1656)

Output String Buffer (+1672..+1716)

A std::string-like growable byte buffer used to accumulate the output filename or module identifier passed in via *(a2+856).

Register-File / Inline Limit Block (+1720..+1768)

Backend Configuration Block (+1840..+1976)

This region holds pointers and dwords copied from the options struct (a2), forming a snapshot of the inputs that drive backend behavior. Many were previously documented as "backend stuff at +18xx".

Post-Instruction Hook Queues + Late Tail (+1984..+2136)

Correction (was "NvOptRecipe / Late Tail"): this region is NOT the NvOptRecipe state. sub_9F4040 (the NvOptRecipe applier, see phase-manager.md → Task IR-24 commit 1ac448a) does not read any offset in [+1984, +2096] on its context parameter. Instead, the region holds two symmetric post-instruction hook queues used by the instruction-append callback dispatcher sub_7DD3C0. Each queue is a {head, tail, count} triple of 8+8+4 = 20 bytes plus 4 bytes of padding per slot, and both queues follow an identical "pending → committed" splice pattern observed in sub_7D92F0:82-161, sub_7B4020:282-348, sub_833E40:210-280, and sub_856260:260-304.

Queue A (committed side only, pending side lives before +1984):

Queue B (full pending + committed, 6-slot triple):

SM Backend Object at +1584

The pointer at context+0x630 (decimal 1584) is the single most confusing field in the compilation context, because it serves multiple roles through a single polymorphic C++ object. Different wiki pages historically called it different names depending on which role they observed:

• Legalization pages see it dispatching MidExpansion, LateExpansionUnsupportedOps, etc., and call it "SM backend" or "arch_backend"
• Scheduling pages see it providing hardware latency profiles at *(sm_backend+372) and call it "scheduler context" or "hw_profile"
• Optimization pages see it dispatching GvnCse (vtable[23]) and OriReassociateAndCommon (vtable[44]) and call it "optimizer state" or "function manager"
• Codegen/template pages see it holding register file capacity at +372 and hardware capability flags at +1037

It is one object. The canonical name is sm_backend. It is constructed per-compilation-unit in sub_662920 with a switch on SM version bits (v3 >> 12). Each SM generation gets a different-sized allocation and a different vtable:

Key sub-fields on the SM backend:

• +372 (i32): codegen factory value / encoded SM architecture version (e.g., 28673 = sm_80)
• +1037 (u8): hardware capability flags (bit 0 = has high-precision FP64 MUFU seeds)
• Vtable slots provide architecture-specific dispatch for 50+ operations

Pipeline Progress Counter at +1552

The field at context+1552 is a monotonically increasing int32 that tracks how far the compilation has progressed through the 159-phase pipeline. It is not a legalization-only counter -- it is incremented by phases across all categories (legalization, optimization, scheduling, regalloc). Each increment is performed by a small thunk function whose sole body is *(ctx + 1552) = N.

Known values and their associated phases:

Readers of downstream passes use *(ctx+1552) > N to gate behavior that should only run after a certain pipeline point. For example, the rematerialization cross-block pass checks *(ctx+1552) > 4 to enable its second-pass mode.

Knob Container Access Pattern

The knob container at +1664 is accessed through a two-level virtual dispatch pattern that appears at 100+ call sites:

// Fast path: known vtable -> direct array read
_QWORD *v2 = *(_QWORD **)(ctx + 1664);
bool (*query)(__int64, int) = *(bool (**)(...))(*v2 + 72);
if (query == sub_6614A0)
    result = *(u8*)(v2[9] + knob_index * 72 + offset) != 0;
else
    result = query((int64)v2, knob_index);  // slow path

The fast path reads directly from the knob value array at v2[9] (offset +72 of the knob state object), where each knob value occupies 72 bytes. The slow path invokes the virtual method for derived knob containers.

Function Context (at +1880)

When a function is under compilation, +1880 points to a large context object containing 17 pairs of analysis-result data structures. Each pair consists of a sorted container and a hash map, holding results such as live ranges, register maps, and scheduling data. The cleanup code in sub_7FB6C0 destroys pairs at qword offsets [102, 97, 92, 87, 82, 77, 72, 67, 62, 57, 52, 47, 42, 36, 31, 26, 21] from the context base, then handles reference-counted objects at offsets [10] and [2].

Opcode Attribute Table (at +776 / +784)

The field at context+776 holds a pointer to a per-opcode attribute bitmap, and context+784 holds the owning allocator. Before this investigation, the ptxas wiki treated both fields as opaque "linked list slots" because they sit adjacent to the call-graph region and the ctor writes to them look like list sentinels. They are neither: they are the storage for a static ~355-entry flag table that every legalization, ISel, and scheduling phase consults to decide how to handle each Ori opcode.

Allocation pattern, reconstructed from sub_7F7DC0_0x7f7dc0.c:904-934:

// Ctor line 904: get master allocator
void *alloc = *(void**)(ctx + 16);

// Ctor line 905: allocate a 1428-byte buffer through vtable[24] (= +24 / 8 = slot 3)
uint8_t *buf = alloc_vtable->allocate(alloc, 1428);

// Ctor line 906: the first 4 bytes of the buffer hold the value 355
// This is NOT an entry count -- the buffer is always 1428 bytes
// regardless of 355 -- it appears to be an opcode-class marker or
// table-version constant checked by the deallocator.
*(uint32_t*)buf = 355;

// Ctor lines 909-927: clear all payload bytes in a 4-qword stride loop
// `v143 = v140 + 178` (= buf + 1424 bytes), so the loop walks indices
// 8, 40, 72, ... 1400 (stride 32). Each iteration touches +0, +8, +16
// (bit-masking the third qword with `&= 0xF8u`, preserving bits 3-7).
// This means each logical entry is **32 bytes** and only the first
// 24 bytes are in the "clean zero" state after init; the fourth qword
// holds pre-set flag bits.

// Ctor lines 932-933: stash pointer and allocator (pointer skips the
// 8-byte header, so `opcode_attr_table[0]` is the bitmap for opcode 0)
*(void**)(ctx + 776) = buf + 8;
*(void**)(ctx + 784) = alloc;

Per-opcode write pattern (ctor lines 934-1229): the ctor issues hundreds of table[byte_offset] |= mask statements, one for each opcode's combination of attributes. A sampling:

Read pattern (observed shape in callers, to be reverse-engineered per phase):

// Gating pattern used by legalization phases:
uint8_t *attr_table = *(uint8_t**)(ctx + 776);
uint8_t flags = attr_table[ori_opcode];  // opcode is 8-bit index into table
if (flags & NEEDS_LATE_EXPANSION)
    schedule_late_expansion(insn);

Each opcode appears to occupy between 1 and 4 bytes in the table, with the exact stride determined by the opcode's class. Because the ctor writes span byte offsets up to 1426 (out of 1420 usable bytes after the 8-byte header) and 355 opcodes * 4 bytes = 1420 bytes, the most likely layout is 4 attribute bytes per opcode -- giving 32 bits of per-opcode flags, of which ~8-10 bits are actively used in the ctor.

Deallocator path (sub_7F7DC0:928-930): when the ctx is freed, the code recovers the original base via v145 = *(_QWORD*)(a1+776); ... free(v145 - 8) -- this is the evidence that +776 points 8 bytes past the allocation base. Without this offset correction, a naive free(*(a1+776)) would corrupt the allocator's metadata.

The table should be treated as partial: each individual bit's meaning needs confirmation by cross-referencing a phase-execute body that actually tests it. The bit positions and inferred roles above come from the ctor init pattern alone.

Ori Code Object (~1136 bytes)

The Code Object is the per-function container for all IR data. One instance exists for each function under compilation. Constructor is at sub_A3B080, vtable at 0x21EE238.

Constructor Analysis

The constructor (sub_A3B080) takes two arguments: a1 (the Code Object to initialize) and a2 (the compilation context). It:

1. Sets +8 = a2 (back-pointer to compilation context)
2. Sets +0 = &unk_21EE238 (vtable)
3. Zeroes approximately 250 distinct fields across the 1136-byte range
4. Loads two SSE constants from xmmword_2027600 and xmmword_21EFAE0 into offsets +96 and +112 (likely default register file descriptors or encoding parameters)
5. Reads a2+1412 and a2+1418 to set mode flags at +1101 and +1008
6. Accesses the knob container at a2+1664 to query knob 367 for initial configuration
7. Sets +1008 = 0x300000050 (default) or 0x400000080 (if a2+1418 & 4)

Code Object Field Map

Register Count Formula

From the stats emitter at sub_A3A7E0 and the register count function at sub_A4B8F0 (which both use vtable+2104 dispatch with sub_859FC0 as the fast path):

total_R_regs      = code_obj[159] + code_obj[102]   // reserved + allocated
instruction_count = code_obj[335] - code_obj[341]   // upper - lower

Stats Emitter Field Map

The stats emitter (sub_A3A7E0) accesses a per-function stats record through the SM backend: v3 = *(compilation_ctx+8)[198] (offset +1584 from the outer compilation context points to the SM backend object; the emitter then reads per-function stats fields within it). It uses DWORD indexing (4-byte), and reveals these additional fields:

Note: The stats emitter accesses the Code Object through a float pointer (v3), so DWORD indices map to byte offsets via index * 4 for integers and index * 4 for floats. Float fields at indices 9, 26, 50, 54, 57, 58, 59, 61, 62, 65, 84, 85, 86 hold throughput and occupancy metrics. A linked list at qword index 55 (byte +440) holds additional string annotations.

Basic Block Representation (two parallel structures)

ptxas uses two separate basic-block containers that coexist in the Code Object, and an earlier draft of this wiki conflated them into a single "40-byte BasicBlock" struct. The conflation is the source of apparent contradictions between this page and the per-pass documentation (which accesses offsets like bb+128, bb+144, bb+152, bb+232, bb+280, bb+292 -- all far beyond 40 bytes). The reality is:

1. bb_array at Code Object +296 -- a dense BasicBlock** table (8-byte stride), i.e. one pointer per block to a heap-allocated full BasicBlock object (≥293 bytes). Used by every optimization pass that needs CFG structure (predecessors, successors, RPO, flags, loop attributes).
2. block_info at Code Object +976 -- an inline contiguous array of 40-byte scheduling descriptors (40-byte stride). Each 40-byte entry is the scheduling / DOT-dumper view of a block and is not a BasicBlock -- it carries an instruction-range bracket (head / tail-sentinel), the block index, and a flag byte.

The two structures are parallel: index i in bb_array and index i in block_info describe the same logical block. Count-wise, bb_array[0..ctx[+304]] is the iteration range (inclusive upper bound), and block_info[0..ctx[+984]] is the iteration range for the 40-byte array (also inclusive). The two counts are set independently but remain in lock-step because the creation paths update both.

The 40-byte block_info entry (at +976)

This is the only structure in ptxas that is actually 40 bytes wide. It is allocated by sub_10AE800 (the block-info appender), which grows the array with capacity_new = max(old*3/2, old+2) and copies 40 * count bytes on reallocation. From sub_10AE800:61:

// sub_10AE800 -- block_info appender
result = (__m128i *)&base[40 * new_count];   // new entry address
*result               = xmm_a7;              // +0..+15  (16 bytes, __int128 arg a7)
result[1]             = xmm_a8;              // +16..+31 (16 bytes, __int128 arg a8)
result[2].m128i_i64[0]= scalar_a9;           // +32..+39 ( 8 bytes, __int64   arg a9)
// Grow path (same function, lines 37-55):
//   v13 = max(cap + (cap+1)/2, count + 2)
//   memcpy(new_buf, old_buf, 40 * old_count);   // i.e. 8 * (5*count + 5)

Field interpretation, cross-checked against the three primary consumers:

Size proof: the appender writes exactly 40 * n bytes, the DOT dumper advances its cursor by literally v9 += 40 per iteration (sub_BE21D0:38), the last-element helper sub_10AE8E0 computes base + 40 * num_blocks, and the grow-path memcpy copies 8 * (5*count + 5) = 40 * (count+1) bytes. Every independent site agrees on stride 40.

40-byte block_info entry layout

  +0   ptr  insn_head               // scheduling-range first instruction
  +8   ptr  insn_tail_sentinel      // scheduling-range terminator
  +16  u64  reserved_a
  +24  i32  scheduling_scratch
  +28  i32  bix                     // unique block index
  +32  u8   flags                   // bit 0x02 set by sub_BE0690 on side-effect terminators
  +33  u8[7] padding

Allocation pseudocode:

function appendBlockInfo(ctx, insn_head, insn_tail, bix, flags):
    // Grow inline array if needed (sub_10AE800)
    count = ctx[+984]
    cap   = ctx[+988]
    if count + 2 > cap:
        new_cap = max(cap + (cap + 1) / 2, count + 2)
        new_buf = arena_alloc(40 * new_cap)       // via code-object allocator vtable+24
        memcpy(new_buf, ctx[+976], 40 * count)
        arena_free(ctx[+976])
        ctx[+976] = new_buf
        ctx[+988] = new_cap

    // Write the new entry
    ctx[+984] = count + 1                         // new high-water index
    entry     = ctx[+976] + 40 * (count + 1)
    entry[+0] = insn_head
    entry[+8] = insn_tail
    entry[+24]= 0
    entry[+28]= bix
    entry[+32]= flags                             // usually 0 at creation
    return entry

The heap BasicBlock object (at *(ctx+296)[bix])

The entries of bb_array point to a much larger heap object. The size has not been pinned down to a single allocator call (it is not created by the 136-byte scratch routine sub_62BB00, whose buffer is sub_4248B0'd back to the arena on the normal exit at line 551), but the minimum size is bounded from below by the field accesses performed by the CFG / liveness / loop passes. The highest confirmed offsets all come from sub_781F80 (BasicBlockAnalysis) through the verified bb_array[] indirection *(_QWORD*)(*(_QWORD*)(a1+296) + 8*bix):

The access at offset +292 (a byte, written with |= 8) sets the lower bound on the BasicBlock size at ≥ 293 bytes, and the natural alignment of the arena allocator rounds this up to a multiple of 8 (so the next valid allocator bucket is 296 bytes). The earlier "BasicBlock = 40 bytes" claim is wrong and was the result of describing the 40-byte block_info entry as if it were the full block object.

The previous revision of this section also misattributed the scheduling-pass initializer sub_8D0640 to the 40-byte array. That was wrong: sub_8D0640 walks a separate linked list rooted at scheduling_ctx[+104] (for (i = *(v21+104); i; i = (__int64*)*i)), with the zeroing pattern i[7] = 0, i[13] = 0, *((_DWORD*)i+19) = 0, *((_DWORD*)i+21) = -1. This linked list stores per-scheduling-group records (qword fields at +56, +104; dword fields at +76, +84), not block_info entries. The 40-byte entries are never rewritten in a single pass like that -- they are populated incrementally during CFG construction via sub_10AE800 and mutated in-place by sub_BE0690 / sub_8A5240 when backedge analysis needs to mark a terminator.

Access cheat sheet

// Iterate every block (optimization / CFG passes)
int bb_count = *(int*)(ctx + 304);                         // inclusive upper bound
for (int i = 0; i <= bb_count; i++) {
    BasicBlock* bb = *(BasicBlock**)(*(ctx + 296) + 8*i);  // 8-byte stride, pointer table
    int rpo  = *(int*)(bb + 144);                          // rpo_number
    int flag = *(int*)(bb + 280);                          // primary flags dword
    ...
}

// Iterate every block (scheduling / DOT dumper)
int n = *(int*)(ctx + 984);                                // inclusive upper bound
char* base = *(char**)(ctx + 976);
for (int i = 0; i <= n; i++) {
    char* entry = base + 40*i;                             // 40-byte stride, inline
    int bix = *(int*)(entry + 28);
    void* insn_head = *(void**)(entry + 0);
    ...
}

Instruction Layout

Instructions are polymorphic C++ objects linked into per-BB doubly-linked lists. The instruction format is detailed in Instructions; this section covers only the structural linkage.

Each instruction carries a unique integer ID at +16, an opcode at +72 (the peephole optimizer masks with & 0xCF on byte 1 to strip modifier bits), and a packed operand array starting at +84. The operand count is at +80. Operands are 8 bytes each.

Packed Operand Format

 31  30  29  28  27       24  23  22  21  20  19                  0
+---+---+---+---+-----------+---+---+---+---+---------------------+
|     type      |  modifier bits (8 bits)    |  index (20 bits)    |
+---+---+---+---+-----------+---+---+---+---+---------------------+

Extraction (50+ confirmed sites):
  uint32_t operand = *(uint32_t*)(instr + 84 + 8 * i);
  int type    = (operand >> 28) & 7;     // bits 28-30
  int index   = operand & 0xFFFFF;       // bits 0-19
  int mods    = (operand >> 20) & 0xFF;  // bits 20-27

The operand classifier functions at 0xB28E00--0xB28E90 provide predicate checks:

Symbol Table

The symbol table is accessed through Code Object +152. Based on the symbol table builder at sub_621480 (21KB, references a1+30016 for the symbol table base), symbols are stored in a hash-map-backed structure where each symbol has a name and associated properties (address, type, section binding).

Internal Symbol Names

The following internal symbol names appear in decompiled code, indicating the kinds of entities tracked:

Symbol Resolution Flow

Symbol resolution (sub_625800, 27KB) traverses the symbol table to resolve references during the PTX-to-Ori lowering and subsequent optimization phases. The format %s[%d] (from sub_6200A0) is used for array-subscripted symbol references, and __$endLabel$__%s markers delimit function boundaries.

Constant Buffer Layout

Constant memory is organized into banks (c[0], c[1], ...) corresponding to the CUDA .nv.constant0, .nv.constant2, etc. ELF sections. The constant section array at Code Object +768 tracks all constant banks for the current function.

Constant Bank Handling

The constant bank handler at sub_6BC560 (4.9KB) manages references to constant memory using the c[%d] (integer bank) and c[%s] (named bank, sw-compiler-bank) notation. It enforces:

• A maximum constant register count (error: "Constant register limit exceeded; more than %d constant registers")
• LDC (Load Constant) requires a constant or immediate bank number

ELF Constant Symbols

The ELF symbol emitter (sub_7FD6C0) creates symbols for constant bank metadata:

The constant emission function (sub_7D14C0, 5.6KB) iterates the constant section array and copies bank data into the output ELF sections.

Shared Memory Layout

Shared memory (.nv.shared) allocations are tracked through the shared memory section array at Code Object +776. Reserved shared memory regions are managed by sub_6294E0 (12.1KB) and sub_629E40 (6.1KB).

Reserved Shared Memory Symbols

The ELF emitter recognizes these special symbols for shared memory layout:

The --disable-smem-reservation CLI option disables the reservation mechanism. Shared memory intrinsic lowering (sub_6C4DA0, 15KB) validates that shared memory operations use types {b32, b64}.

Descriptor Size Symbols

Additional ELF symbols track texture/surface descriptor sizes in shared memory:

Pool Allocator

The pool allocator (sub_424070, 3,809 callers) is the single most heavily used allocation function. Every dynamic data structure in ptxas is allocated through pools.

Pool Object Layout

Allocation Paths

Small path (size <= 4999 bytes = 0x1387):

1. Round size up to 8-byte alignment: aligned = (size + 7) & ~7
2. Minimum 16 bytes
3. Compute bin: bin = pool + 8 * (aligned >> 3) + 2128
4. If bin has a free block: pop from free list, decrement slab available bytes
5. If bin is empty: allocate a new slab from the parent (size = aligned * ceil(min_slab_size / aligned)), carve into free-list nodes

Large path (size > 4999 bytes):

1. Add 32 bytes for boundary tags
2. Search power-of-2 order free lists starting from log2(size+32)
3. If found: split block if remainder > 39 bytes, return payload
4. If not found: call sub_423B60 to grow the pool, allocate new slab from parent

Boundary Tag Format (Large Blocks)

Large blocks use boundary tags for coalescing on free:

Block Header (32 bytes):
  +0    i64      sentinel      // -1 = allocated, else -> next free
  +8    ptr      prev_free     // previous in free list (or 0)
  +16   u64      tag_offset    // 32 (header size)
  +24   u64      payload_size  // user-requested allocation size

Block Footer (32 bytes at end):
  +0    i64      sentinel
  +8    ptr      prev_free
  +16   u64      footer_tag    // 32
  +24   u64      block_size    // total size including headers

Slab Descriptor (56 bytes)

Each slab is tracked by a 56-byte descriptor:

Hierarchical Pools

Pools are hierarchical. When sub_424070 is called with a1 = NULL, it falls back to a global allocator (sub_427A10) that uses malloc directly. Non-null a1 values are pool objects that allocate from their own slabs, which are themselves allocated from a parent pool (the TLS context at offset +24 holds the per-thread pool pointer). The top-level pool is named "Top level ptxas memory pool" and is created in the compilation driver.

Hash Map

The hash map (sub_426150 insert / sub_426D60 lookup, 2,800+ and 422+ callers respectively) is the primary associative container in ptxas.

Hash Map Object Layout (~112 bytes)

Hash Modes

The hash mode is encoded in bits 4-7 of the flags field at offset +84:

Mode selection happens automatically in the constructor (sub_425CA0): if the hash/compare pair matches (sub_427750, sub_427760), mode 2 is set; if (sub_4277F0, sub_427810), mode 1.

Lookup Algorithm

// Mode 1 (pointer hash) example:
uint64_t hash = (key >> 11) ^ (key >> 8) ^ (key >> 5);
uint64_t bucket_idx = hash & map->bucket_mask;
int32_t* chain = map->buckets[bucket_idx];
while (*++chain != -1) {
    entry_t* e = map->entries + 16 * (*chain);
    if (key == e->key)
        return e->value;  // found
}
return 0;  // not found

Growth policy: the map doubles capacity and rehashes when entry_count > load_factor_threshold.

String-Keyed Maps

String-keyed maps use MurmurHash3 (sub_427630, 73 callers) as the hash function. The implementation uses the standard MurmurHash3_x86_32 constants:

CFG Hash Map (FNV-1a)

The control flow graph uses a separate hash map implementation based on FNV-1a hashing, distinct from the general-purpose hash map above. Two instances exist per Code Object at offsets +648 (successor edges) and +680 (backedge info).

Bucket entry: 24 bytes {head, tail, count}. Node: 64 bytes with chain link, key, values, sub-hash data, and cached hash. See CFG for the full CFG hash map specification.

Linked List

The linked list (sub_42CA60 prepend, 298 callers; sub_42CC30 length, 48 callers) is a singly-linked list of 16-byte nodes:

ListNode (16 bytes, pool-allocated)
  +0    ptr      next        // pointer to next node (NULL = end)
  +8    ptr      data        // pointer to payload object

Prepend allocates a 16-byte node from the pool, sets node->data = payload, and links it at the list head. This is used for function lists, relocation lists, annotation chains, and many intermediate pass-local collections.

Growable Array (Pool Vector)

Growable arrays appear throughout the PhaseManager and elsewhere. The layout is a triple of {data_ptr, count, capacity}:

PoolVector (24 bytes inline, or embedded in parent struct)
  +0    ptr      data         // pointer to element array
  +8    i32      count        // current element count
  +12   i32      capacity     // allocated capacity

Growth strategy (confirmed in the PhaseManager timing records): new_capacity = max(old + old/2 + 1, requested) (1.5x growth factor). Elements are typically 8 bytes (pointers) or 16 bytes (pointer pairs). Reallocation uses sub_424C50 (pool realloc, 27 callers).

The PhaseManager uses this pattern for the phase list (16-byte {phase_ptr, pool_ptr} pairs), the name table (8-byte string pointers), and the timing records (32-byte entries).

Knob Value Array

Knob values are stored in a contiguous array of 72-byte slots, accessed at knob_state[9] + 72 * knob_index (where knob_state[9] is offset +72 of the knob state object).

Knob Value Slot (72 bytes)

Supported types:

Knob Descriptor (64 bytes)

Knob descriptors are stored in a table at knob_state+16, with count at knob_state+24:

Stream Object

The output stream used for diagnostics and stats reporting (e.g., at compilation context +1440) is a C++ iostream-like object with operator overloads. Field layout (from sub_7FE5D0 and sub_7FECA0):

ORI Record Serializer (sub_A50650)

The ORI Record Serializer (sub_A50650, 74 KB, 2,728 decompiled lines) is the central function that takes a Code Object's in-memory state and flattens it into a linear output buffer organized as a table of typed section records. It is the serialization backbone for both the DUMPIR diagnostic subsystem and the compilation output path. Despite the _ORI_ string it contains, it is not an optimization pass -- it is infrastructure.

Parameters

a1 is a serialization state object ("OriRecordContext") that carries the section table, compilation context back-pointer, and per-subsection index/size pairs. a2 is the output buffer write cursor, advanced as data is emitted.

Key fields on a1:

Section Record Format

Each section occupies a 32-byte entry in the table at *(a1+72) + 32 * section_index:

Offset  Type   Field
+0      u16    type_tag           section type identifier
+4      u32    data_size          byte size of data payload
+8      ptr    data_ptr           pointer to data in output buffer
+16     u32    element_count      number of elements (or auxiliary metadata)
+20     u32    aux_field          additional per-type context
+24     u32    aux_field_2        secondary per-type context

Data payloads are 16-byte aligned: cursor += (size + 15) & ~0xF.

Section Type Tag Catalog

The serializer emits up to 56 unique section types across three tag ranges.

Base types (0x01--0x58):

Extended types (0x1208--0x1221): Emitted only when *(char*)(ctx+1412) < 0, which enables the full post-register-allocation diagnostic mode. These 16 types carry per-register-class live range and operand definition data:

The _ORI_ Name Prefix

The _ORI_ string is not a pass name. At line 1762 the serializer iterates the linked list at v7+55 (the original-definition chain maintained for rematerialization debugging) and for each entry creates a string "_ORI_<original_name>":

// Line 1748-1770 (simplified)
for (def = v7->original_defs; def; def = def->next) {
    entry = &section_table[16 * (state->instr_offset + idx)];
    entry->type_tag = 34;      // original-definition name
    entry->data_ptr = cursor;
    strcpy(cursor, "_ORI_");
    strcpy(cursor + 5, def->name);
    cursor += align16(strlen(def->name) + 21);
}

These names are consumed by the register allocation verifier (sub_A55D80) when it compares pre- and post-allocation reaching definitions. A mismatch triggers the "REMATERIALIZATION PROBLEM" diagnostic (string at 0xa55dd8), which lists original definitions under their _ORI_ names alongside the post-allocation state.

Wrapper: sub_A53840

sub_A53840 (48 lines) is a thin wrapper that:

1. Emits a type-44 header record if *(ctx+1600)[1193] is set (scheduling metadata header)
2. Calls sub_A50650 with the output buffer
3. Optionally emits a type-62 trailer record if *(ctx+1600)[48] is set

This wrapper is the typical entry point reached through vtable dispatch.

Function Map

Related Pages

• Ori IR Overview -- top-level IR design, Code Object field summary
• Instructions -- detailed instruction format and encoding
• CFG -- FNV-1a hash map CFG implementation
• Registers -- register descriptor layout
• Phase Manager -- PhaseManager object layout, phase dispatch
• Memory Pool Allocator -- full allocator internals
• Hash Tables & Bitvectors -- hash map and bitvector details
• Knobs System -- knob descriptors, value types, ROT13 encoding
• Entry Point & CLI -- compilation driver, options block