NVVM IR Node Layout

The NVVM frontend in cicc v13.0 uses a custom intermediate representation distinct from LLVM's native IR. Each IR node is a variable-length structure allocated from a bump allocator, with operands stored backward from the node header pointer. The node uniquing infrastructure lives in sub_162D4F0 (49KB), which routes each opcode to a dedicated DenseMap inside the NVVM context object.

Node Header Layout

The pointer a1 returned from allocation points to the start of the fixed header. Operands are at negative offsets behind it.

Minimum header size is 24 bytes. Total node allocation: 24 + 8 * num_operands bytes minimum, though opcode-specific extra fields extend the header region for certain node types.

Operand Storage

Operands are stored as 8-byte QWORD pointers at negative offsets from the header. The stride is exactly 8 bytes per operand. Access follows this pattern (decompiled from sub_162D4F0):

operand[k] = *(_QWORD *)(a1 + 8 * (k - num_ops))

For a node with num_operands = 3:

• operand[0] is at a1 - 24
• operand[1] is at a1 - 16
• operand[2] is at a1 - 8

A 2-operand node occupies 40 bytes total (16 operand bytes + 24 header bytes). A node with opcode 0x1B and 5 operands requires approximately 88 bytes (40 operand bytes + ~48 header bytes including extra fields).

Tagged Pointer Semantics

The context_ptr at offset +16 uses low-bit tagging to encode indirection:

• Bits [2:0] = 0: pointer is a direct reference to the context object.
• Bit [2] = 1: pointer is an indirect reference (pointer-to-pointer).

The decompiled dereferencing pattern:

v = *(a1 + 16) & 0xFFFFFFFFFFFFFFF8;  // mask off tag bits
if (*(a1 + 16) & 4)                    // bit 2 set = indirect
    v = *v;                             // one extra dereference

This technique saves a field by encoding the indirection flag inside the pointer itself, relying on 8-byte alignment guarantees.

Opcode Dispatch Table

The uniquing function sub_162D4F0 performs a byte-level switch on *(_BYTE *)a1. Each case extracts the tagged context pointer, dereferences it, then probes an opcode-specific DenseMap for a structurally identical node.

Uniquing Opcode Dispatch (sub_162D4F0, 49KB)

The opcodes fall into two categories: "simple" opcodes that use sub-function tables at fixed stride, and "complex" opcodes that use dedicated DenseMap instances at individually-known offsets.

Simple opcodes (0x04--0x15) -- These 18 opcodes share a uniform dispatch pattern. Each routes to a sub-function table at a fixed byte offset within the context object, spaced 32 bytes apart:

Each sub-function table entry at these offsets is a 32-byte structure containing the callback address and metadata for hash-table probing.

Complex opcodes (0x16--0x22) -- These opcodes each own a full DenseMap within the context object. Each DenseMap occupies 4 qwords at the indicated base, plus associated dword counters:

Opcodes 0x1C, 0x1D, and 0x1E read the subopcode field at *(unsigned __int16 *)(a1 + 2) as part of the hash key, because these node types require the intrinsic ID to distinguish structurally identical nodes with different semantic meaning.

Hash Function

Every DenseMap in the uniquing tables uses the same hash:

hash(ptr) = (ptr >> 9) ^ (ptr >> 4)

Hash computation for multi-operand nodes (sub_15B3480) extends this by combining the hash of each operand pointer with a mixing step. The hash seed is the opcode byte, then each operand is folded in:

seed ^= hash(operand[i]) + 0x9E3779B9 + (seed << 6) + (seed >> 2);

Sentinel values: empty = -8 (0xFFFFFFFFFFFFFFF8), tombstone = -16 (0xFFFFFFFFFFFFFFF0).

Node Erasure (sub_1621740, 14KB)

The mirror of insertion. Dispatches by the same opcode byte, finds the node in the corresponding DenseMap, overwrites the bucket with the tombstone sentinel (-16), and decrements NumItems while incrementing NumTombstones. When tombstone count exceeds NumBuckets >> 3, a rehash at the same capacity is triggered to reclaim tombstone slots.

Bitcode Instruction Opcode Table

NVIDIA uses LLVM's standard instruction opcode numbering with minor adjustments. The bitcode reader sub_166A310 / sub_151B070 (parseFunctionBody, 60KB/123KB) dispatches on a contiguous range. The NVVM verifier sub_2C80C90 confirms the mapping via its per-opcode validation switch:

The binary opcodes in the 0x23--0x34 range follow LLVM's BinaryOperator numbering:

InstCombine Internal Opcode Table

The InstCombine mega-visitor sub_10EE7A0 (405KB, the single largest function in cicc) uses a different opcode numbering -- the full LLVM Instruction::getOpcode() values rather than the bitcode record codes. These are accessed via sub_987FE0 (getOpcode equivalent). Key ranges observed:

The NVIDIA custom opcodes (0x2551, 0x255F, 0x254D) are in a range far above standard LLVM and handle CUDA-specific operations (texture, surface, or warp-level ops encoded as custom IR nodes) that have no upstream LLVM equivalent.

NVVM Context Object

The context object referenced by context_ptr is a large structure (~3,656 bytes, confirmed by the destructor sub_B76CB0 at 97KB which tears down a ~3656-byte object) containing uniquing tables for every NVVM opcode, plus type caches, metadata interning tables, and allocator state.

Context Layout Overview

Simple Opcode Table Region (+496..+1136)

The 18 entries for opcodes 0x04 through 0x15 (plus a few extras) are 32-byte structures at fixed offsets:

struct SimpleOpcodeTable {
    void  *buckets;       // +0:  heap-allocated bucket array
    int32  num_items;     // +8:  live entry count
    int32  num_tombstones; // +12: tombstone count
    int32  num_buckets;   // +16: always power-of-2
    int32  reserved;      // +20: padding
    void  *callback;      // +24: hash-insert function pointer (or NULL)
};

Byte offsets increase monotonically: +496, +528, +560, +592, +624, +656, +688, +720, +752, +784, +816, +848, +880, +912, +944, +976, +1008, +1072, +1104, +1136.

Complex Opcode DenseMap Region (+1040..+1424)

Each DenseMap for a complex opcode occupies 4 qwords plus associated dword counters:

struct OpcodeUniqueMap {
    int64  num_entries;    // qw[N]:   includes tombstones
    void  *buckets;        // qw[N+1]: heap-allocated bucket array
    int32  num_items;      // dw[2*N + offset]: live entries
    int32  num_tombstones; // dw[2*N + offset + 1]: tombstone count
    int32  num_buckets;    // dw[2*N + offset + 2]: capacity (power-of-2)
};

Complete mapping:

Destructor (sub_1608300, 90KB)

The context destructor confirms the layout by freeing resources in order:

1. Calls j___libc_free_0 on bucket pointers at offsets +272 through +792 (stride 32) -- frees all 16 simple opcode hash tables.
2. Destroys sub-objects via sub_16BD9D0, sub_1605960, sub_16060D0 -- these tear down the complex DenseMap instances and any heap-allocated overflow chains.
3. Releases vtable-referenced objects at offsets +200, +224, +248.

The separate LLVMContext destructor (sub_B76CB0, 97KB) frees 28+ hash tables from the full ~3,656-byte context structure, confirming that the uniquing tables are only part of the overall context.

Type Tag System

The context object's hash tables also serve as uniquing tables for type nodes. The byte at offset +16 in each IR node encodes the type tag (distinct from the opcode byte at +0):

The type tag at +16 is used by InstCombine (sub_1743DA0) and many other passes to quickly classify nodes without reading the full opcode. The observed range is 5--75, considerably denser than standard LLVM's Value subclass IDs.

Instruction Creation Helpers

NVIDIA's LLVM fork provides a set of instruction creation functions that allocate nodes from the bump allocator, insert them into the appropriate uniquing table, and update use-lists. These are the core IR mutation API:

Primary Instruction Factories

Opcode Constants for Creation

These numeric opcode values are passed as the first argument to sub_B504D0:

Node Builder / Cloner (sub_16275A0, 21KB)

The IR builder at sub_16275A0 creates new nodes by cloning operand lists from a source node, using the tagged pointer Use-list encoding described above. It dispatches to three specialized constructors:

All three ultimately route through the uniquing function sub_162D4F0 to deduplicate structurally-identical nodes.

Infrastructure Functions

Allocation

NVVM IR nodes are allocated from a slab-based bump allocator:

• Slab growth: 4096 << (slab_index >> 7) -- exponential, capped at 4TB.
• Alignment: 8 bytes (pointer aligned via (ptr + 7) & ~7).
• Deallocation: no individual free; entire slabs are released at once.
• Overflow: triggers a new slab via malloc().

This is the standard LLVM BumpPtrAllocator pattern, consistent with how upstream LLVM manages IR node lifetimes. The lack of per-node deallocation means the NVVM frontend cannot reclaim memory for dead nodes until the entire context is destroyed.

Cross-References

• DenseMap / Hash Infrastructure -- universal hash function and DenseMap layout
• DAG Node -- SelectionDAG-level node layout (104-byte SDNode)
• NVVM Container -- the NVVMPassOptions/container that wraps the context
• Bitcode I/O -- bitcode opcode encoding and parseFunctionBody
• InstCombine -- the 405KB mega-visitor that consumes these nodes
• NVVM Verifier -- per-opcode validation rules

Function Map