SM75 Turing

The SM75 (Turing, compute capability 7.5) instruction selection backend occupies 984 KB at 0xF16000--0x100C000 and is the largest single-architecture ISel backend in the nvlink v13.0.88 binary. It contains 1,737 functions organized into four functional layers -- operand predicates, instruction emitters, pattern matchers, and post-ISel emit+encode functions -- plus a 280 KB mega-hub dispatch function (sub_FBB810) that is the largest function in the entire binary at 65,999 instructions.

Turing is architecturally significant as the first SM generation to introduce the Uniform Register File (URF), which manifests throughout this backend as operand kind 10 (UREG). The ISel uses a priority-based linear scan: for each IR instruction, all 276 pattern matchers run in sequence, and the highest-priority match wins.

Key Facts

Address Map

Instruction Selection Flow

For each NVVM IR instruction to be lowered to SM75 machine code, sub_FBB810 executes the following protocol:

1. sub_FBB810 iterates through all 276+ pattern matchers
2. Each matcher calls sub_A49150(ctx, node, field_id) to read instruction attributes
3. Each matcher calls sub_530FD0(node) to check explicit operand count
4. Each matcher calls sub_530FB0(node, idx) to retrieve operand at index
5. Each matcher calls sub_530FC0(node) to check implicit operand count
6. Operand type checked via sub_F16040/F16070/etc predicates (kind tag)
7. Register class validated via sub_F16030: value 1023 = "any" (wildcard)
8. If all checks pass: *priority_out = priority, *pattern_id_out = id
9. After all matchers run, mega-hub picks highest-priority match
10. Corresponding emitter called to generate 128-bit encoding

The priority mechanism ensures specific patterns override general ones. Higher values win. If the current best priority already exceeds a matcher's threshold, that matcher early-outs (optimization to avoid redundant checks). Priority ranges across the 276 matchers:

Operand Predicates

Fifteen trivial inline functions at 0xF16030--0xF160F0 classify operand types by a single-byte tag at operand offset +0. These are the leaves of every pattern-match tree.

The identity function at 0xF16030 is used as both a register-class accessor (return value compared against 1023/1/2/4/5) and a generic field value passthrough. A second identity function at 0xF16130 has a different type signature in the original source (both compile to identical machine code, but they occupy distinct vtable slots).

The predicate pair sub_F160B0 / sub_F160C0 is always called as sub_F160B0(v) || sub_F160C0(v) -- accepting either PT (always true, kind 3) or PN (always false, kind 15), matching the SASS convention where a predicate guard can be either polarity.

Operand Kind Tag Summary

Kind 10 (UREG) is the defining Turing addition. It reflects the Uniform Register File introduced in SM75, which provides scalar registers shared across all threads in a warp. This operand kind appears pervasively in the pattern matchers, often alongside kind 2 (REG) as alternatives in the same operand slot.

Register Class IDs

Instruction Emitters

Eighteen functions at 0xF10080--0xF15A50 implement the "emit" phase of instruction selection. Each takes an emitter context (a1, 576+ bytes) and an instruction node (a2) and produces the SM75 128-bit instruction encoding. All share a common structure:

Phase 1: Set instruction opcode at a2+12 (e.g., 126, 18, 104)
Phase 2: Load register class descriptor from rodata into a1+8 (SSE load)
Phase 3: Populate 10-slot operand descriptor arrays at a1+24..a1+140
         (register IDs, types, flags -- using SSE memcpy for speed)
Phase 4: Set explicit operand count at a1+144
Phase 5: Bind operands via sub_4C6380/sub_4C60F0/sub_4C6DC0
Phase 6: Encode bitfields into encoding words at a1+544 and a1+552
Phase 7: Set instruction class tag at a1+276
Phase 8: Write branch target / relocation info to instruction node

Identified Emitters

Opcode Families

Three instruction opcode numbers are confirmed from a2+12 assignments:

Instruction Class Tags

The 5-byte value written at context offset +276 encodes both the instruction family (high nibble) and operand configuration (low word):

Pattern Matchers

All 276 pattern matchers at 0xF16150--0xFBB780 share the same signature:

char __fastcall sm75_match_XXX(
    void*     ctx,          // a1: ISel context
    void*     instr_node,   // a2: IR instruction node
    uint32_t* pattern_id,   // a3: output -- matched pattern ID
    uint32_t* priority      // a4: in/out -- current best priority
);

Each performs a deeply-nested sequence of checks:

1. Check instruction attributes via sub_A49150(ctx, node, field_id) -- see field ID dictionary below
2. Check explicit operand count via sub_530FD0(node)
3. For each explicit operand: validate kind tag and register class
4. Check implicit operand count via sub_530FC0(node)
5. For each implicit operand: validate kind tag and register class
6. If all checks pass and *a4 <= threshold: set *a4 = new_priority, *a3 = pattern_id

Pattern Matcher Categories

The 276 matchers group into 12 functional categories by the instruction families they match:

Complex HMMA Matchers (Largest)

The most complex matchers target Half-precision Matrix Multiply-Accumulate (HMMA) instructions for Turing's tensor cores. These are the largest individual matcher functions (6--8 KB each) because HMMA has the most operands and encoding options:

sub_F77140 -- HMMA widest variant A (8,408 bytes, 179 lines):

• Checks field 0x216 == 2717 (HMMA opcode variant)
• Additional checks: fields 0xA1 == 700, 0xA2 in range 702--703
• 1 explicit operand: register R128
• 9 implicit operands: R128 x3, predicate, R64, R32, UREG R32, PT/PN check
• Sets pattern_id=8, priority=39 (maximum observed)

sub_F77DF0 -- HMMA widest variant B (8,401 bytes, 179 lines):

• Checks field 0x21A == 2729 (different HMMA subtype)
• Same 9-implicit-operand structure
• Sets pattern_id=12, priority=39

sub_F76DD0 -- HMMA wide operand A (7,226 bytes, 164 lines):

• Checks field 0x216 == 2716
• 1 explicit R128 + 8 implicit (R128 x3, predicate, R32, UREG x2)
• Sets pattern_id=7, priority=34

Fallback Matcher

sub_FBB780 (1,108 bytes, 34 lines) is the fallback pattern that matches when nothing else does:

• Zero instruction attribute checks
• Requires: explicit operand count == 0, implicit count == 2, first implicit = uniform register R32
• Sets pattern_id=1, priority=2 (lowest observed)
• Any other matching pattern will override this due to priority 2

Post-ISel Emit+Encode Functions

Thirty-eight functions at 0xFFFDF0--0x100BBF0 combine pattern matching with instruction encoding for complex instructions requiring immediate bitfield packing. They share the emitter signature __int64 (ctx, instr_node) and use sub_4C28B0(ctx, bit_offset, width, value) extensively to pack individual fields into the 128-bit SASS instruction word.

Encoding Protocol

1. Pack opcode bits:     sub_4C28B0(a1, 0, 4, 2)   -- 4 bits at offset 0
2. Pack sub-opcode:      sub_4C28B0(a1, 4, 3, 0)   -- 3 bits at offset 4
3. Pack encoding fields from rodata tables
4. Initialize operand binding via sub_4C2A60/sub_4C2A90
5. Extract instruction-specific modifiers via sub_A551C0..sub_A55470
6. Encode modifiers into bit positions via sub_A4xxxx/sub_A50xxx
7. Pack into encoding words at ctx+544 and ctx+552 (shift+OR)
8. Set relocation metadata at ctx+148..ctx+160

Identified Emit+Encode Functions

The remaining 20 emit+encode functions (0x1002EA0--0x10083A0) follow the same structure with varying field encoding positions and are labeled as generic variants (I through AA).

Opcode distribution among emit+encode functions: 11 for FP32 (opcode 104), 8 for integer ALU (opcode 18), 2 for memory (opcode 126), 17 for undetermined variants.

Encoding Context Structure

The 576-byte emitter context is the central data structure threading through all emitter and emit+encode functions. It accumulates the operand bindings and bitfield encodings for one SM75 SASS instruction.

Offset  Size   Field
+0      8      Reserved / vtable pointer
+8      16     XMM register class descriptor (SSE-loaded from rodata)
+12     2      Instruction opcode number (18, 104, or 126)
+16     4      Base bit position for predicate encoding
+24     40     Operand register numbers: 10 x 4-byte slots (indices 0--9)
+64     40     Operand types / constraints: 10 x 4-byte slots
+104    40     Operand flags: 10 x 4-byte slots (0=def, 1-5=use, -1=unused)
+144    4      Explicit operand count
+148    4      Relocation type (first)
+152    4      Relocation bit offset (first)
+156    4      Relocation type (second)
+160    4      Relocation bit offset (second)
+276    8      Instruction class tag (e.g., 0xE000000004)
+404    32     Match/emit dispatch table pointer
+536    8      Pointer to instruction descriptor table
+544    8      Encoding word 0 (64-bit bitfield, low half of 128-bit)
+552    8      Encoding word 1 (64-bit bitfield, high half of 128-bit)
+558    2      Immediate value (16-bit)
+572    4      Branch/offset target

The operand descriptor arrays at offsets +24, +64, and +104 are populated with optimized SIMD memcpy (aligned SSE loads/stores copying 4 elements at a time from rodata descriptor tables).

Rodata Register Class Descriptors

Each instruction family has a 16-byte register class descriptor loaded from rodata into context offset +8 via SSE:

Each descriptor has three parallel arrays of 10 DWORDs defining per-slot operand register IDs, type/constraint descriptors, and flag words. Example for memory operations: dword_1F46E38[0..9] (register IDs), dword_1F46E60[0..9] (types), dword_1F46E88[0..9] (flags).

External Dependencies

The SM75 backend relies on shared infrastructure functions used across all ISel backends:

IR Node Accessors

Operand Binding Functions

Modifier Extraction and Encoding

Modifier fields are extracted from the IR node via sub_A55xxx functions and encoded into bit positions via sub_A4xxxx/sub_50xxxx functions:

Additional encoding functions handle specific operand attributes: sub_509D90 (register source A), sub_509DB0 (register source B), sub_509F20 (comparison mode), sub_509160 (data type/precision), sub_509290 (rounding mode), sub_509890 (saturation/clamp), sub_50AC80 (source negate/abs), sub_50ACD0 (source modifier composite), sub_509800 (address mode), sub_509930 (thread scope), sub_509A90 (memory order), sub_50C820 (cache policy), sub_50B570 (texture mode).

Field ID Dictionary

Field IDs passed to sub_A49150 to query instruction attributes. These are the keys used by every pattern matcher to classify instructions:

Turing-Specific Design Observations

Uniform Register File (URF). SM75 introduced the uniform register file -- scalar registers whose value is identical across all threads in a warp. This eliminates redundant per-lane computation for warp-uniform values. In the ISel backend, UREG (kind 10) appears as a first-class operand type alongside REG (kind 2). Many pattern matchers accept either kind in the same operand slot, reflecting that SASS instructions can take operands from either the general or uniform register file.

HMMA complexity. The tensor core (HMMA) instruction family drives the most complex patterns in this backend. The R128 register class (ID 4) exists specifically for HMMA, representing four consecutive 32-bit registers that hold matrix fragments. The highest-priority matchers (priority 39) are all HMMA variants, and the largest individual matcher functions (8+ KB) target HMMA.

Linear scan architecture. Unlike tree-pattern matchers (as used in LLVM's TableGen-generated ISel), this backend evaluates all patterns sequentially. The 280 KB mega-hub calls each of the 276 matchers in order, collects the highest-priority match, then dispatches to the winning emitter. This is computationally expensive (O(patterns) per instruction) but simple to extend: adding a new pattern requires only inserting a new matcher function into the sequence.

128-bit instruction encoding. SM75 uses 128-bit SASS instructions (two 64-bit words at context offsets +544 and +552). The sub_4C28B0 primitive packs arbitrary-width bit fields at arbitrary positions within these two words. Modifier fields are extracted from the IR node and encoded at precise bit positions, with different emit+encode variants differing only in which bits they set within the 128-bit word.

Confidence Assessment

For general SM75 architecture details, see the ptxas wiki: Turing/Ampere and cicc wiki: SM70-89.

Cross-References

nvlink Internal

• Embedded ptxas: Architecture Overview -- full address map including SM75 backend position
• Instruction Selection Hubs -- the five mega-hub dispatch functions
• IR Nodes -- IR node structure and accessor functions
• Architecture Dispatch -- SM75 vtable registration and callbacks
• Architecture Profiles -- SM75 profile in the linker database
• SM80 Ampere -- successor ISel backend

Sibling Wikis

• ptxas: Turing/Ampere -- standalone ptxas SM75/SM80 target documentation
• ptxas: ISel -- standalone ptxas instruction selection
• cicc: SM70-89 -- cicc compiler SM75 through SM89 targets