IR Node Infrastructure

The IR node subsystem is the central data structure layer of the embedded ptxas backend. Every instruction, operand, and modifier field in the compiler pipeline is represented as an IR node or a field within one. Two functions dominate the entire binary by call count: sub_530FB0 (IRNode_GetOperand, 31,399 callers) returns a pointer to the Nth operand of any IR node, and sub_A49150 (NVInst::getOperandField, 30,768 callers) reads any named field from any instruction. Together they form the universal accessor layer through which every optimization pass, instruction selector, register allocator, and encoder interacts with instructions. This page documents the IR node structure layout, the operand slot format, the NVInst instruction object (a ~1,550-byte structure initialized by an 11 KB constructor), and the four giant operand dispatch switches that total 453 KB of compiled code.

Key Functions

IR Node Primitives (0x530E80--0x530FD0)

Twenty-two leaf functions at the bottom of the call graph. Most are single-instruction predicates or field extractors.

NVInst Accessor Methods (0xA49010--0xA49F80)

Higher-level accessors on the instruction object. These operate on the full NVInst structure (not the minimal IR node used by ISel patterns).

Giant Operand Dispatch Switches (0xA5B6B0--0xA67910)

Four massive switch-on-opcode functions that implement per-instruction read/write of operand fields. Each switch has hundreds of cases (one per opcode ID), and each case contains a nested switch on field ID.

NVInst Constructor

IR Node Structure Layout

The minimal IR node structure is accessed by the 22 leaf functions at 0x530E80--0x530FD0. This is the structure passed to ISel pattern matchers and MercExpand handlers -- a lightweight view of any instruction or operand.

IRNode (minimum 96 bytes, exact total size unknown)
============================================================
Offset  Size  Field                  Description
------------------------------------------------------------
  0      1    type_tag               Operand type (1-16, see Operand Types below)
  4      4    reg_class              Register class ID; 1023 = wildcard "any"
 14      1    flag_a                 General-purpose flag byte A
 15      1    flag_b                 General-purpose flag byte B
 20      4    data_type              Data type / secondary encoding field
 28      2    opcode                 IR opcode (0xFFFF = invalid/terminator)
 32      8    operand_array_ptr      Pointer to operand array (each entry = 32 bytes)
 40      4    total_operand_count    Total number of operands (sources + destinations)
 92      4    first_src_index        Index of first source operand

Operand counts are derived:

• Source operands = total_operand_count + 1 - first_src_index (via sub_530FC0)
• Destination operands = first_src_index (via sub_530FD0)
• Get operand N = operand_array_ptr + 32 * N (via sub_530FB0)

The +1 in the source operand formula means total_operand_count stores the index of the last operand (inclusive upper bound), not the count. If an instruction has 4 operands numbered 0-3, total_operand_count = 3 and first_src_index = 1 (one destination, three sources).

Operand Slot Layout

Each operand occupies exactly 32 bytes within the operand array. The slot format is used both by the lightweight IR node accessors and by the giant dispatch switches.

OperandSlot (32 bytes)
============================================================
Offset  Size  Field                  Description
------------------------------------------------------------
  0      1    type_tag               Operand kind (see Operand Types)
  4      4    value                  Register number, immediate value, or symbol ID
  8      8    (pointer/extended)     Pointer to symbol, constant buffer, etc.
 16      1    modifier_a             Modifier byte 1 (negation, absolute value, etc.)
 17      1    modifier_b             Modifier byte 2 (type coercion, reuse flag, etc.)
 20      4    reg_class              Register class for this operand
 24      4    packed_encoding        Packed bitfield for instruction encoding
 28      4    constraint             Operand constraint ID

The packed_encoding field at offset +24 is the key data structure for the getOperandField/setOperandField dispatch functions. It stores multiple sub-fields as packed bit-fields. The 2-bit and 3-bit extractors (sub_A4D1E0 and sub_A4D150) read sub-fields from this word (and from DWORD arrays for wider instructions) by bit position.

Operand Types

The type_tag byte at offset +0 in both the IR node and each operand slot encodes the operand kind. All 16 values have been identified from the 22 leaf predicate functions at 0x530E80--0x530FD0, the 10 operand initializer functions at 0x4C5F90--0x4C6DC0, the two NVOperand constructors at 0xA49020/0xA49040, and the ISel pattern matcher call sites.

Operand Type Tag Architecture Invariance

The type tag encoding is identical across all supported architectures. Three sets of per-arch clones of the predicate functions exist in the binary:

All clones test the same integer constants. No architecture adds, removes, or renumbers any tag.

Identity Operand Table

The NVOperand::isIdentity function (sub_A49060) determines whether an operand holds its type's default (no-op) value. The logic:

bool isIdentity(char *operand) {
    uint8_t tag = operand[0];
    if (tag > 11) return false;           // tags 12-16 are never identity
    if (((1LL << tag) & 0xFF6) == 0)      // bitmask: types 1,2,4,5,6,7,8,9,10,11
        return false;                      // excludes type 0 and type 3 (Symbol)
    uint8_t idx = tag - 2;
    int identity = (idx <= 9) ? dword_1E31200[idx] : 31;
    return operand[4] == identity;         // value at offset +4
}

The identity lookup table at 0x1E31200 (10 entries, indexed by type_tag - 2):

The identity values match the PTX ISA conventions: RZ is register 255, PT is predicate 7, URZ is uniform register 63. The bitmask 0xFF6 = 0b111111110110 excludes type 0 (unused) and type 3 (Symbol -- symbols have no identity value since every symbol is unique).

The companion function sub_A48FE0 (NVOperand::setToIdentity) initializes an operand to its identity state:

void setToIdentity(char *operand, uint8_t tag) {
    operand[0] = tag;                     // set type
    uint8_t idx = tag - 2;
    operand[4] = (idx <= 9) ? dword_1E31200[idx] : 31;
    operand[20] = 1;                      // reg_class = 1 (default)
}

Operand Initializer Functions

The instruction descriptor init table uses 10 specialized initializer functions. Each allocates a 32-byte operand slot, sets the type tag, decodes register or value fields from the instruction bitstream at inst+544, and optionally updates the first_src_index counter at a2+92.

NVInst Object Layout

The full NVInst instruction object is a ~1,550-byte structure initialized by the 11 KB constructor at sub_A4AB10. This constructor takes 31 parameters including an allocator, architecture ID, format ID, name string, mnemonic string, and various configuration values. The object is organized as ~97 x 16-byte (m128i) slots, many holding ref-counted pointers to sub-lists.

NVInst (~1550 bytes, 16-byte aligned)
============================================================
Offset   Size   Field                  Description
------------------------------------------------------------
   0       8    allocator              Pointer to arena allocator
  16      48    instr_list_node        Instruction linked-list (prev/next/head)
  64      32    bb_membership          Basic block membership node
  96      32    sched_graph_node       Scheduling dependency graph node
 128      32    operand_list           Ref-counted pointer to operand list
 132       4    flags                  Instruction flags (see Flag Bits below)
 160      32    output_operands        Ref-counted output operand list
 192       8    modifier_flags         Packed modifier bitfield
 200       4    arch_class_id          Architecture class identifier
 204       4    format_id              Instruction format identifier
 208       4    arch_id                SM architecture version
 224       8    opt_level              Optimization level (from dword_1E311D0 table)
 232       8    sched_mode             Scheduling mode (from dword_1D4AED0 table)
 240      32    name_str               Heap-allocated instruction name string
 272      48    mnemonic_str           Heap-allocated mnemonic string
 320      48    output_operand_list    Ref-counted list for output operands
 368      32    input_operand_list     Ref-counted list for input operands
 400       8    isa_vtable             ISA-specific virtual dispatch table pointer
 408       8    isa_backend            Pointer to ISA-specific backend object
 416      48    isa_state              ISA-specific state (initialized by vtable[7])
 464      48    predicate_chain        Ref-counted predicate chain list
 512      16    mem_dep_flags          Memory dependency classification flags
 528      32    sched_dep_list         Scheduling dependency ref-counted list
 560      ...   reg_file_state         Register file state, use-def chains, etc.
 976       8    operand_vec_data       Pointer to dynamic operand vector
 984       4    operand_vec_size       Current number of 40-byte operand entries
 988       4    operand_vec_capacity   Allocated capacity
1064       8    side_effect_cache      Cached side-effect analysis result
1080      72    instr_type_hashtable   FNV-1a hash table for instruction type lookups
1136       1    analysis_flags_lo      Classification bits (see Analysis Flags)
1137       1    analysis_flags_hi      Extended classification bits

Construction Sequence

The constructor at sub_A4AB10 follows this sequence:

1. Store the allocator pointer at slot 0.
2. Allocate 8+ ref-counted list objects for: instruction list, basic block list, operand list, use-def chains, modifier lists, register mappings. Each allocation calls a release helper (sub_A4A050--sub_A4A3D0) for exception safety.
3. Store architecture/format IDs at offsets 200--208.
4. Copy the name string via strlen + memcpy into offsets 240--271.
5. Copy the mnemonic string into offsets 272--319.
6. Allocate additional ref-counted lists for output operands, input operands, predicate operands, scheduling dependencies, and memory dependencies.
7. Call sub_52DAB0(arch_id) to obtain the ISA-specific vtable.
8. Store the vtable at offset 400 and call vtable[7] for ISA-specific initialization.
9. Initialize flag bytes, counters, and sentinel values (0xFFFFFFFF).
10. Compute optimization level from parameter a5 via the dword_1E311D0 lookup table (5 entries).
11. Compute scheduling mode from parameter a7 via the dword_1D4AED0 lookup table (4 entries).

Instruction Flag Bits (offset +132)

Analysis Flag Bits (offset +1136)

Set by sub_A49B50 (analyzeInstructionFlags) after instruction decoding:

Operand Dispatch Architecture

The four giant switch functions at 0xA5B6B0--0xA67910 are the read/write interface between the abstract IR operand model and the physical instruction encoding. They total 453 KB of compiled code. All four share the same architectural pattern: a top-level switch on *(inst+12) (the opcode ID, hundreds of cases), with each case containing a nested switch on the field ID.

setOperandField (sub_A5B6B0, 180 KB)

void setOperandField(NVInst *inst, uint32_t field_id, uint32_t value);

Outer switch on opcode ID dispatches to ~200 per-opcode sub_50Cxxx/sub_50Dxxx setter functions. Each setter writes bit-fields into the instruction encoding bitstream (starting at offset +536 in the NVInst object). The bit extraction formula:

// Writing a field at bit position pos with width w:
uint64_t *word = (uint64_t *)(inst + 8 * (pos >> 6) + 544);
uint64_t mask  = ((1ULL << w) - 1) << (pos & 0x3F);
*word = (*word & ~mask) | ((uint64_t)value << (pos & 0x3F));

Some fields are set via a normalized subtraction pattern: setter(inst, value - base_value) where base_value is the minimum legal value for that field (shared across many goto labels like LABEL_3923 and LABEL_3935).

setOperandImm (sub_A62220, 65 KB)

void setOperandImm(NVInst *inst, uint32_t slot_idx, uint32_t field_id, uint64_t value);

Accesses the operand slot at *(inst+32) + 32*slot_idx. Writes the immediate value into the packed_encoding word at offset +24 within the operand slot using XOR-swap:

*(operand + 24) ^= (old_bits ^ new_bits) & mask;

Dispatches to per-opcode sub_5195xx--sub_519Axx setter functions.

getOperandField (sub_A65900, 67 KB)

uint32_t getOperandField(NVInst *inst, uint32_t slot_idx, uint32_t field_id);

Reads from the packed_encoding word. Uses the 2-bit and 3-bit extractors:

• sub_A4D1E0 (extractBitField2): extracts 2 bits at a given position, handles cross-DWORD boundary
• sub_A4D150 (extractBitField3): extracts 3 bits, same cross-boundary handling

Typical return pattern: extractBitField2(operand + 24, bit_offset) + base_value, where base_value maps the extracted bits back to an enumeration value (e.g., register class ID).

Returns 0xFFFFFFFF if the field is not present for the given opcode.

getDefaultOperandValue (sub_A67910, 141 KB)

uint32_t getDefaultOperandValue(NVInst *inst, uint32_t field_id);

Structurally identical to setOperandField but calls setters with hardcoded constant values rather than user-supplied values. Used during instruction creation to initialize all fields to their default (identity/NOP) values. Example: sub_50C9B0(inst, 1278) sets a modifier field to its default encoding.

The getOperandField Wrapper (sub_A49150)

This 60-byte function is the single most important accessor in the binary. With 30,768 callers, it is called from virtually every optimization pass, instruction selector, register allocator, and code generator:

uint32_t NVInst_getOperandField(void *this, NVInst *inst, uint32_t field_id) {
    // sub_A7DE70: giant switch -- does the instruction have this field?
    if (hasOperand(inst, field_id)) {
        // sub_A709F0: giant switch -- extract the field value
        return getOperandValue(inst, field_id);
    }
    return 0xFFFFFFFF;  // field not present
}

The two-phase lookup (existence check then value extraction) means every field access performs two opcode switch dispatches. This is the cost of supporting a fully generic instruction representation that must handle 365+ distinct opcodes with varying operand schemas.

Instruction Descriptor Init Table (0x920240--0xA48290)

943 template-instantiated functions, each initializing one instruction variant's descriptor. Every function follows this template:

1. Opcode assignment: *(desc+12) = opcode_id (range: 15--365+).
2. Register class descriptor: Load 16-byte mask from .rodata via SSE into *(inst+8).
3. Operand format tables: Three parallel arrays of 10 DWORDs each:
   • inst+24..+60: operand register class IDs
   • inst+64..+100: operand constraint IDs
   • inst+104..+140: operand modifier IDs
4. Operand count: *(inst+144) = N (range: 1--16).
5. Per-operand init calls: N calls to type-specific initializers:

6. Modifier field decoders: N calls to sub_50xxxx/sub_51xxxx functions that extract modifier fields from the instruction bitstream at inst+536..+560+.

Opcode Frequency

The most common opcodes, indicating which instruction families have the most encoding variants:

Function size correlates directly with operand count: 2--4 operand instructions produce ~4 KB functions, 3--6 operands produce ~5 KB, 6--10 operands produce ~6 KB, and the most complex instructions (10--16 operands, e.g., LDG wide-register variants) produce ~7 KB functions.

FNV-1a Hash Table Infrastructure

The instruction descriptor layer uses FNV-1a hash tables for opcode-to-descriptor lookups. The hash parameters:

• Offset basis: 0x811C9DC5 (standard FNV-1a 32-bit)
• Prime: 16777619 (0x01000193)
• Application: byte-by-byte on the key, XOR-then-multiply

Two specializations exist:

FNVHash<uint64_t> (sub_A4B770)

• Key: 8 bytes (instruction ID or pointer)
• Node size: 168 bytes. Layout: {next[0], key[8], value_data[16..160], hash[160]}
• Value: 280 bytes copied via SSE (instruction metadata)
• Rehash trigger: collision_count > entry_count AND entry_count > capacity/2
• Growth: 4x current capacity

FNVHash<uint32_t> (sub_A4C360)

• Key: 4 bytes (opcode ID)
• Node size: 32 bytes. Layout: {next[0], key[8], value_ptr[16], hash[24]}
• Value: pointer to 160-byte descriptor allocated via sub_4FDC30
• Same rehash strategy via sub_A4C1D0

Both implementations use bucket arrays with 24-byte buckets ({head_ptr, tail_ptr, count}) and singly-linked chains within each bucket.

Bit-Field Extraction Helpers

Two small functions used extensively by the getOperandField dispatch:

• sub_A4D1E0 (extractBitField2): Extracts a 2-bit field from a packed DWORD array at a given bit position. Handles cross-DWORD boundary by combining shifted values from adjacent DWORDs.
• sub_A4D150 (extractBitField3): Same pattern for 3-bit fields, mask & 7.

Both return 0 if the field position exceeds the array bounds.

Instruction Query Methods

The NVInst object provides a set of classification methods that other passes query:

Use-Def Chain Infrastructure

The use-def chain structure (sub_A49F80, constructor at 0xA49F80) is allocated as part of the NVInst's register file state. It initializes:

NVUseDefChain (104+ bytes)
============================================================
Offset  Size  Field
  0      4    def_id         Initially -1 (0xFFFFFFFF)
  4      4    flags          Initially 1
  8      8    parent_ptr     Pointer to owning NVInst
 16      4    sentinel       Initially 0xFFFFFFFF
 24     32    use_list       Ref-counted list of uses
 64     32    def_list       Ref-counted list of definitions

Use-def chains are the fundamental data structure for SSA-based optimizations in the ptxas backend.

Read-Only Data Tables

Cross-References

nvlink Internal

• Embedded ptxas Overview -- full address map showing IR node location at 0x530000--0x620000
• ISel Hubs -- ISel mega-hubs that consume IR nodes via sub_530FB0 and sub_A49150
• Register Allocation -- regalloc pass that reads/modifies IR node register fields
• Peephole -- peephole passes that rewrite IR node operands

Sibling Wikis

• ptxas: IR Overview -- standalone ptxas Ori IR architecture
• ptxas: IR Instructions -- Ori instruction representation
• ptxas: IR Registers -- register file and classes
• ptxas: IR Data Structures -- CFG and data structure internals