Pass Inventory & Ordering

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

The ptxas compilation pipeline consists of exactly 159 phases, executed in a fixed order determined by a static index table at 0x22BEEA0. Every compilation traverses the same sequence -- phase skipping is handled per-phase via isNoOp() virtual method overrides, not by reordering the table. This page is the definitive inventory of all 159 phases: their index, name, category, one-line description, and cross-references to detailed documentation where available.

All 159 phases have names in the static name table at off_22BD0C0 (159 entries, indexed 0--158). The factory switch at sub_C60D30 allocates each phase as a 16-byte polymorphic object with a 5-slot vtable: execute() at +0, getIndex() at +8 (returns the factory/table index), and isNoOp() at +16 (returns 0 for active phases, 1 for phases skipped by default). Slots +24 and +32 are NULL.

Phase Categories

Each phase is tagged with one of 10 categories. These are not present in the binary -- they are an analytical classification applied during reverse engineering.

Phases 139--158 are late-pipeline phases covering Mercury encoding, scoreboards, register map computation, diagnostics, and a terminal NOP. They have the same vtable infrastructure as phases 0--138 and are fully named in the static table.

Numbering Discrepancy -- Complete Wiki-to-Binary Mapping

Warning: The wiki phase numbers 0--138 use a compressed scheme that omits 23 binary indices from the contiguous range 0--139. Of these 23, seven are displaced to wiki positions 132--138, and 16 have no wiki number at all. The divergence begins at binary index 8 (UpdateAfterConvertUnsupportedOps, skipped in the wiki) and accumulates to a delta of +23 by wiki phase 116. Phases 140--158 match their binary indices. Every cross-reference on this page and 40+ linked pages uses wiki numbers, NOT binary indices. Use the table below to convert.

Complete Binary-to-Wiki Translation Table

Reading guide: W# = wiki phase number used on this page. Rows marked SKIP have no wiki number (16 phases). Rows marked DISP are displaced to wiki 132--138 (7 phases). Delta = binary index minus wiki number.

Phases 140--158 are identity-mapped (wiki number = binary index). The full list appears in Stage 10 below. Note that binary 139 (ProcessO0WaitsAndSBs) appears at BOTH wiki 116 (in Stage 7) and wiki 139 (in Stage 10).

16 Phases Missing from Wiki Numbering

These binary phases have no wiki number. All are valid DUMPIR and DisablePhases targets.

7 Displaced Phases (Wiki 132--138)

These phases exist in the binary at early/mid positions but were assigned wiki numbers 132--138 when discovered after the initial compressed numbering was established. Their true execution order follows their binary index, not their wiki number.

Gate Passes (AdvancedPhase)

Seventeen phase instances (16 unique gates, plus AdvancedPhaseOriPhaseEncoding appearing at both wiki 127 and 152) are conditional extension points whose isNoOp() returns true in the default vtable. They exist as insertion points for architecture backends and optimization-level overrides. When a specific SM target or -O level requires additional processing at a given pipeline position, the backend overrides the phase's vtable to provide a real execute() implementation.

Gate passes bracket major pipeline transitions. For example, phases 4 and 7 bracket ConvertUnsupportedOps (phase 5), allowing a backend to inject pre- and post-legalization logic without modifying the fixed phase table. Phase 101 (AdvancedPhaseAllocReg) is the most critical gate -- the entire register allocation subsystem is driven through this hook; the base pipeline contains no hardcoded allocator.

The naming convention is consistent: AdvancedPhase prefix followed by the pipeline position or action name. One exception is AdvancedScoreboardsAndOpexes (phase 115), which uses Advanced without Phase.

Gate Pass Worker Correspondence

All 17 gate passes fall into three categories when activated by a backend override: (A) dispatch to a named worker phase from the static name table, (B) dispatch through an SM backend vtable slot at ctx+0x630, or (C) execute a pipeline progress counter thunk that writes ctx+1552 = N. Category A gates have a named worker visible to DUMPIR. Category B dispatches through architecture-specific code in the SM backend object. Category C gates' only effect is advancing the pipeline progress counter, which downstream passes read via *(ctx+1552) > N guards.

Type A gates (5) dispatch to a named worker phase in the static name table -- valid DUMPIR/NamedPhases/DisablePhases targets. AdvPhEarlyEnforceArgs was reclassified from C to A based on P5_02 evidence: it dispatches to EnforceArgumentRestrictions [48], with LateEnforceArgumentRestrictions [103] as its late counterpart. Type B gates (5) dispatch through an SM backend vtable slot at ctx+0x630; the worker code lives in the per-SM backend object. Specific vtable offsets: +0x168 (late sync expansion), +0x178 (late unsupported ops), +0x110 (post-reg-attr, guarded by default-impl check against nullsub_170@0x7D6C80). Type C gates (6) write ctx+1552 (pipeline_progress) to values 1--21, forming a monotonically increasing timeline that 20+ downstream guards check. AdvPhPostSched was reclassified from B to C based on P0_03 evidence: sub_C5E830 is a 7-byte thunk writing ctx+1552 = 14, identical in structure to the other progress thunks.

See Optimization Levels for per-gate activation rules.

Update Passes

Nine phases refresh data structures invalidated by preceding transformations. Six are documented at specific wiki phase numbers; three additional update phases exist in the static name table but are not yet mapped to wiki phase numbers (see Numbering Discrepancy above):

These are lightweight passes that call into the IR's internal consistency maintenance routines. They do not transform the IR -- they only update auxiliary data structures (liveness bitmaps, instruction lists, block layout caches) so that downstream passes see a coherent view. Phases 150 and 154 are late-pipeline duplicates whose isNoOp() returns 1 by default; they only activate when a backend requires a second update cycle. The three *(true N)* entries are in the static name table at the indicated indices but are not yet assigned wiki phase numbers.

Report Passes

Ten phases produce diagnostic output. They are no-ops unless specific debug options are enabled (e.g., --stat=phase-wise, DUMPIR, --keep):

Phase 131 (DebuggerBreak) is a development-only hook that triggers a breakpoint -- it is not a report pass per se, but serves a similar diagnostic purpose. Phase 157 is its late-pipeline counterpart (empty body in release builds).

GeneralOptimize Bundles

The GeneralOptimize* passes are compound optimization bundles that run multiple small transformations (copy propagation, constant folding, algebraic simplification, dead code elimination) in a fixed-point iteration until no further changes occur. They appear at 6 positions throughout the pipeline to re-clean the IR after major transformations:

See GeneralOptimize Bundles for the sub-pass decomposition.

O-Level Gating

Mechanism

The 159-phase pipeline does not carry any opt-level metadata on the phase objects themselves. Three binary facts establish this:

1. Uniform phase construction. sub_C60D30 (the 159-case phase factory at 0xC60D30, 1132 lines) allocates every phase object via the same 5-line body: request 16 bytes from the pool, store a per-case vtable pointer at offset +0, store the allocator pointer at +8, return. There is no *(char*)(obj+N) = LEVEL write anywhere in the switch; every case is byte-identical except for the vtable symbol (cases 0--158 at sub_C60D30_0xc60d30.c:172--1125, tail default at 1126--1129). The 16-byte phase object therefore has room for exactly {vtable, allocator} and no inline "minimum opt level" field.

2. The dispatch loop does not consult opt-level. sub_C64F70 (the phase iterator at 0xC64F70, 276 lines) calls each phase's isNoOp() virtual (vtable slot +0x10) twice per iteration, and then unconditionally calls the phase's execute() virtual (vtable slot +0x00) via LABEL_4:

   // sub_C64F70:86 (first isNoOp check)
   if ( (*(unsigned __int8 (**)(__int64))(*(_QWORD *)v6 + 16LL))(v6) )
     goto LABEL_4;             // skips "Before <phase>" diagnostic print
   /* ... allocate & emit "Before <name>" diagnostic string ... */
   LABEL_4:
     (**(void (***)(__int64, __int64))v6)(v6, *a1);   // execute(ctx)
   // sub_C64F70:162 (second isNoOp check)
   if ( !(*(unsigned __int8 (**)(__int64))(*(_QWORD *)v6 + 16LL))(v6) )
     /* ... allocate & emit "After <name>" diagnostic string ... */
   

   The goto LABEL_4 branch bypasses only the diagnostic-string formatting block (lines 88--159); control still falls through to execute() at line 161. isNoOp() is therefore a diagnostic-suppression flag, not an execution gate. The pre-execute call at line 86 hides the "Before" string; the post-execute call at line 162 hides the "After" string; the execute() body itself runs every iteration regardless. See Phase Manager -- Phase Dispatch Loop for the full annotated dispatch pseudocode and the isNoOp timing discussion.

3. The gate lives inside each execute body. Phases that honour the -O level do so via an early-return prologue in their execute() thunk. The canonical pattern (instantiated ~82 times in the 0xC5F7xx--0xC60Bxx range) is:

   // sub_C60140 (representative execute thunk, 8 bytes + prologue)
   void PhaseN::execute(ocg_ctx* ctx) {
     if ( (int)sub_7DDB50(ctx) > 1 )    // opt_level > 1 (i.e. O2+)
       sub_XXXXXX(ctx);                  // tail-call real implementation
     // else: fall through -- phase was a no-op at this O-level
   }
   

   sub_7DDB50 (the opt-level accessor at 0x7DDB50, 232 bytes) reads the cached 32-bit opt_level field from ocg_ctx + 2104 (i.e. ctx + 0x838), but only when knob 499 is active; otherwise it returns 1, capping effective behaviour at O1. The knob-499 kill-switch and the iteration-budget counter at kv->state[35940] are documented in Optimization Levels -- Gate Accessor.

Important corollary. Because execute() is always invoked, every phase's timing record and pre-snapshot (written at sub_C64F70:72--85, before the first isNoOp() call) are also recorded. --ftime output therefore contains a row for all 159 phases in every compilation, including phases that immediately early-returned because the opt-level guard failed. Gated-off phases show near-zero elapsed time rather than being omitted.

Pseudocode for the full gate mechanism

// OCG context fields referenced by the gate
struct ocg_ctx {
    // ...
    void*      options_mgr;       // +0x680 (1664)  -- knob query vtable
    int32_t    opt_level_cached;  // +0x838 (2104)  -- parsed -O level, 0..5
    // ...
};

// sub_7DDB50 (0x7DDB50) -- opt-level accessor, called by each phase execute
int getOptLevel(ocg_ctx* ctx) {
    OptionsMgr* om  = ctx->options_mgr;           // [ctx+1664]
    auto        set = om->vtable->setOption;      // [vtbl+152]
    if (set == sub_67EB60) {
        auto isSet = om->vtable->isOptionSet;     // [vtbl+72]
        bool knob_499 = (isSet == sub_6614A0)
            ? (om->state[35928] != 0)             // direct bss read
            : isSet(om, 499);                     // virtual query
        if (!knob_499)
            return ctx->opt_level_cached;         // honour -O level
        int used = om->state[35940];              // iteration counter
        if (om->state[35936] > used) {            // budget not exhausted?
            om->state[35940] = used + 1;
            return ctx->opt_level_cached;         // honour -O level
        }
    } else if (set(om, 499, 1)) {
        return ctx->opt_level_cached;             // honour -O level
    }
    return 1;                                     // fallback: clamp to O1
}

// Per-phase execute prologue (replicated in ~82 wrapper thunks)
void Phase_execute(phase* self, ocg_ctx* ctx) {
    if ((int)getOptLevel(ctx) > 1) {              // the gate: O2+ only
        do_the_actual_work(ctx);                  // tail-call real pass
    }
    // else: phase is a runtime no-op for this compilation
}

// sub_C64F70 dispatch loop (pseudocode; isNoOp() only gates diagnostics)
void PhaseManager::dispatch(int* idx, int n) {
    for (int i = 0; i < n; i++) {
        phase* p = phases[idx[i]];
        append_timing_record(p);                  // unconditional
        take_pre_snapshot();                      // unconditional
        if (!p->isNoOp()) print("Before " + p->name);
        p->execute(ctx);                          // ALWAYS called
        if (!p->isNoOp()) print("After "  + p->name);
    }
}

The matrix is regular (two-bucket structure at the wrapper layer)

Scanning all phase wrappers in 0xC5F7xx--0xC60Bxx (the per-phase execute thunks) for calls to sub_7DDB50:

Zero layer-1 wrappers use the thresholds > 0 (would mean "O1+"), > 2 ("O3+"), > 3 ("O4+"), or > 4 ("O5 only"). Fine-grained opt-level branching (e.g. opt_level <= 2 in sub_78DB70, <= 3 in sub_914B40, > 2 in sub_8FB5D0 / sub_9FC860 / sub_9F8C00, > 3 in sub_137EE50) happens inside the implementation bodies, after the wrapper has already let control through. Those internal decisions toggle sub-algorithms (e.g. forward vs. reverse scheduler pass, loop-peeling depth, remat strategy) rather than enabling or disabling the phase as a whole.

The phase-to-O-level activity matrix is therefore regular: the layer-1 wrapper either runs the phase at every level, or gates it at exactly one threshold (opt_level > 1). Per-phase irregularity exists only at layer 2 -- inside the implementations that the wrappers call. This collapses the "159 phases × 6 opt-levels" table to a two-column classification at the outer dispatch layer:

+------------------------------+-------------------------------------+
|  Category A: always-run       |  Category B: O2+ only               |
|  (no sub_7DDB50 in wrapper)   |  (wrapper: sub_7DDB50(ctx) > 1)     |
+------------------------------+-------------------------------------+
|  * All reporting/dump phases  |  * GVN-CSE, LICM, rematerialization |
|  * All validation phases      |  * Loop unrolling, software pipe    |
|  * All legalization phases    |  * Predication / if-conversion      |
|  * All Mercury/SASS encoding  |  * Switch/branch optimization       |
|  * All register-allocation    |  * Sync-instruction optimization    |
|  * All AdvancedPhase gates    |  * Barrier removal                  |
|  * All pseudo/expansion phases|  * Backward copy propagation        |
|  * Initial setup & cleanup    |  * Speculative hoisting, peephole   |
+------------------------------+-------------------------------------+

Concrete -O0 vs -O3 phase lists

Resolving the gate with opt_level = 0 (i.e. sub_7DDB50 returns 0) against the 159-phase pipeline and the Category-B wrappers identified above:

At -O0, the following phases early-return (runtime no-ops): Phase 14 DoSwitchOptFirst (gate sub_C5F720), 15 OriBranchOpt (sub_C5F950), 22 OriLoopUnrolling, 24 OriPipelining, 26 OriRemoveRedundantBarriers, 28 SinkRemat, 30 DoSwitchOptSecond (sub_C5FC80), 38 OptimizeNestedCondBranches (sub_C5FA70), 49 GvnCse, 54 OriDoRematEarly, 58 GeneralOptimizeLate (sub_C603E0, unless option-31 override), 63 OriDoPredication, 69 OriDoRemat, 71 OptimizeSyncInstructions, 72 LateExpandSyncInstructions, 95 SetAfterLegalization, 99 OriDoSyncronization, 100 ApplyPostSyncronizationWars, 110 PostSchedule, 115 AdvancedScoreboardsAndOpexes, and ~60 other Category-B phases. At -O0 the scheduling subsystem does still run phase 116 ProcessO0WaitsAndSBs, which performs the conservative-scoreboard insertion that makes O0 code actually executable -- phase 116 is itself a Category-A wrapper that dispatches to sub_C5E2A0 only when the target architecture has sm_version > 0x3FFF.

At -O3 (the default), every Category-A wrapper runs, and every Category-B wrapper also runs because sub_7DDB50 returns 3 which satisfies > 1. The difference between -O2 and -O3 at the wrapper level is therefore zero phases -- both levels activate the same 159 wrappers. The -O2/-O3 distinction happens entirely inside the implementation bodies (e.g. scheduling direction in sub_8D0640, which branches on opt_level > 2). The same is true for -O3 vs. -O4 vs. -O5: identical layer-1 wrapper activation, different internal algorithm selection. Only the -O0 and -O1 thresholds produce layer-1 visible skips.

This two-tier design explains why the wiki's "O-Level" column in the 159-phase table below is sparse: most phases have no entry because they always run (Category A) or because the visible O-level branching is buried inside a layer-2 implementation and does not show up at the phase wrapper at all.

See Optimization Levels for the confirmed per-phase threshold list, the detailed sub_7DDB50 accessor breakdown, knob 499 kill-switch semantics, the NvOpt recipe system, and the scheduler/RA-specific opt-level interactions.

Complete 159-Phase Table

Stage 1 -- Initial Setup (Phases 0--13)

Program validation, recipe application, FP16 promotion, control flow analysis, unsupported-op conversion, macro creation, initial diagnostics.

Stage 2 -- Early Optimization (Phases 14--32)

Branch/switch optimization, loop canonicalization, strength reduction, software pipelining, SSA phi insertion, barrier optimization.

Stage 3 -- Mid-Level Optimization (Phases 33--52)

GVN-CSE, reassociation, shader constant extraction, CTA/VTG expansion, argument enforcement.

Stage 4 -- Late Optimization (Phases 53--77)

Predication, rematerialization, loop fusion, varying propagation, sync optimization, phi destruction, uniform register conversion.

Stage 5 -- Legalization (Phases 78--96)

Late unsupported-op expansion, backward copy propagation, GMMA fixup, register attributes, final validation.

Stage 6 -- Scheduling & Register Allocation (Phases 97--103)

Synchronization insertion, WAR fixup, register allocation, 64-bit register handling.

Stage 7 -- Post-RA & Post-Scheduling (Phases 104--116)

Post-expansion, NOP removal, hot/cold optimization, block placement, scoreboard generation.

Scoreboard generation has two mutually exclusive paths. At -O1 and above, phase 115 (AdvancedScoreboardsAndOpexes) runs the full dependency analysis using sub_A36360 (52 KB) and sub_A23CF0 (54 KB DAG list scheduler), while phase 116 is a no-op. At -O0, phase 115 is a no-op and phase 116 inserts conservative stall counts.

Stage 8 -- Mercury Backend (Phases 117--122)

SASS instruction encoding, expansion, WAR generation, opex computation, microcode emission.

"Mercury" is NVIDIA's internal name for the SASS encoding framework. WAR generation runs in two passes (119, 121) because instruction expansion in phase 118 can introduce new write-after-read hazards. The MercConverter infrastructure (sub_9F1A90, 35 KB) drives instruction-level legalization via a visitor pattern dispatched through sub_9ED2D0 (25 KB opcode switch).

Stage 9 -- Post-Mercury (Phases 123--131)

Register map computation, diagnostics, debug output.

Stage 10 -- Late Cleanup & Late Pipeline (Phases 132--158)

Late merge operations, late unsupported-op expansion, high-pressure live range splitting, Mercury encoding pipeline, register map computation, diagnostics, and debug hooks.

Phases 139--158 are 20 late-pipeline phases whose vtable pointers range from off_22BEB80 to off_22BEE78 (40-byte stride, 20 * 0x28 bytes). All 20 have names in the static table at off_22BD0C0 (159 entries -- the earlier wiki note claiming "139 entries" was based on a compressed model that excluded these phases). Name resolution for the dispatch-loop diagnostic (sub_C64F70) goes through the static table indexed by getIndex() at vtable+8.

Vtable layout (3 slots, 24 bytes per object, off_22BExxx). Every late-pipeline phase object has exactly three virtual methods:

The phase object itself is 16 bytes: [0]=vtable*, [8]=ctx*. No per-phase instance state -- all state lives in the shared OCG context passed to every execute() call.

isNoOp statistics. 16 of 20 phases return 0 from isNoOp() (diagnostics printed). Exactly 4 phases return 1 (diagnostics suppressed): 150, 151, 152, 154. Of those, three (150, 151, 154) also have nullsub execute bodies and are truly vestigial; phase 152 has an 11-byte body that writes pipeline_progress = 21 but is hidden from dumps because it is a state-tracking marker, not an IR transform.

Phase-by-phase deep dive (139--158)

Each entry gives: execute function address, body size in bytes, vtable address, gate condition (if any), and pseudocode. All addresses are verified via (a) the factory switch in sub_C60D30 (cases 139--158 at lines 1006--1125), (b) the raw pointer-table dump at 0x22BEB80--0x22BEE78 read from .rodata, and (c) direct objdump of the .text segment.

Phase 139 ProcessO0WaitsAndSBs -- vtable=0x22BEB80 -- execute sub_C5E2A0 (41 bytes, IDA missed it, recovered via objdump). Runs on sm50+ only. Tail-dispatches to the target's ApplyConservativeScoreboards hook (vtable slot 0x150) with flag edx=1 (O0 mode). On sm30 / sm_3x and pre-sm50 architectures the phase returns immediately because the legacy shader-processor scoreboard model does not apply.

mov  rdi, [rsi+0x630]          ; rdi = ocg_ctx->target
cmp  dword [rdi+0x174], 0x3FFF ; if sm_version_encoded <= 16383 (pre-sm50)
jle  .return                   ;   skip
mov  rax, [rdi]                ; target.vtable
mov  edx, 1                    ; mode = O0
jmp  [rax+0x150]                ; target->ApplyConservativeScoreboards(ctx,1)
.return:
ret

isNoOp returns 0 (sub_C5E2E0, 3 bytes). No pipeline_progress write.

Phase 140 PostFixUp -- vtable=0x22BEBA8 -- execute sub_C5E270 (13 bytes). Unconditional target-hook dispatch. Every Mercury target registers a post-fixup method at vtable slot 0x148; non-Mercury targets install a nullptr-safe stub. The method performs target-specific cleanup after schedule and register allocation are final (examples: texture barrier placement on Volta, scoreboard packing on Turing+).

mov  rdi, [rsi+0x630]          ; target
mov  rax, [rdi]                ; target.vtable
jmp  [rax+0x148]                ; target->PostFixUp(target)

isNoOp = 0 (sub_C5E290).

Phase 141 MercConverter -- vtable=0x22BEBD0 -- execute sub_C60300 (8 bytes, thunk) -> body sub_9F3760. Second MercConverter invocation, re-running the 35 KB opcode-dispatch machinery from phase 5 (ConvertUnsupportedOps) on instructions introduced by optimization passes (rematerialization, peephole, loop transforms) that may carry unlegalized PTX-derived opcodes. Internal gate testb $0x10, [rdi+0x570] (bit 4) inside sub_9F3760 makes the body an immediate return on non-Mercury targets. When enabled the body dispatches on target.sm_code at [rdi+0x174] with the arch constants 0x9000/0x7005/0x7001/0x6001 to pick a per-generation conversion path. After completion every IR instruction carries a valid SASS opcode ready for encoding. See Mercury sub_9F1A90 / sub_9ED2D0 for the full opcode dispatch.

; execute thunk
mov  rdi, rsi                  ; rdi = ocg_ctx
jmp  0x9F3760                  ; MercConverter::Run

; sub_9F3760 prologue
testb [rdi+0x570], 0x10        ; Mercury-active bit
jz   .return
...

Phase 142 MercEncodeAndDecode -- vtable=0x22BEBF8 -- execute sub_C60310 (8 bytes, thunk) -> body sub_18F21F0. Encodes each Ori IR node to its Mercury-node form via sub_6D9690 (the master encoder), then round-trip-decodes to verify the binary encoding is reversible. After this phase all subsequent pipeline stages operate on Mercury nodes exclusively. Internal gate testb $0x2, [rdi+0x571] (bit 1 of the high byte of ctx+0x570) makes it a no-op when Mercury is not the active backend.

mov  rdi, rsi
jmp  0x18F21F0                 ; MercEncodeAndDecode::Run

; body prologue
testb [rdi+0x571], 0x2
jz   .return
mov  r15, [rdi+0x788]          ; Mercury context
test r15, r15
jz   .return
...

Phase 143 MercExpandInstructions -- vtable=0x22BEC20 -- execute sub_C60320 (16 bytes). Expands compound Mercury pseudo-instructions (e.g. multi-word branches, multi-step LDG/STG sequences, sm_120 TCGEN05 macros) into their SASS primitives. Gated by ctx+0x570 bit 5; the Mercury backend sets this bit during its init recipe. Tail-calls sub_C3DFC0 (102 bytes, an orchestrator that calls sub_C3CC60 to iterate the Mercury list and invokes per-instruction vtable+0x40 Expand hooks). sub_C3DFC0 also emits the "After MercExpand" diagnostic on completion.

testb [rsi+0x570], 0x20        ; bit 5: MercExpandEnable
jnz  .active
repz ret                        ; skip -- non-Mercury target
.active:
mov  rdi, [rsi+0x788]          ; rdi = Mercury context
jmp  0xC3DFC0                  ; RunMercExpandPass

Phase 144 MercGenerateWARs1 -- vtable=0x22BEC48 -- execute sub_C60340 (16 bytes). First WAR-hazard annotation pass. Walks the Mercury node list and tags each consumer with the write-after-read stall counts needed to satisfy the target's hazard model. Runs after MercExpandInstructions (143) but before MercGenerateOpex (145); the "pass-1" naming reflects that two WAR passes are needed because Opex (145) can rewrite operand banks and introduce new write-to-read distances that pass 146 then re-annotates. Gated by the sign bit (cmpb $0, [rsi+0x570]; js i.e. bit 7) of ctx+0x570.

cmpb [rsi+0x570], 0             ; js = "if signed" = bit 7 set
js   .active
repz ret
.active:
mov  rdi, [rsi+0x788]
jmp  0x6FC240                  ; RunMercWARsPass (47 bytes)

Phase 145 MercGenerateOpex -- vtable=0x22BEC70 -- execute sub_C60380 (16 bytes). Generates Opex (operand-exchange) annotations per instruction -- extra control bits that tell the hardware which physical register bank to read each operand from, required by the sm_90+ banked-register file to avoid bank conflicts. Gated by ctx+0x570 bit 6. Tail-calls sub_7032A0 (472 bytes, RunMercOpexPass). See Mercury Stage 4.

testb [rsi+0x570], 0x40
jnz  .active
repz ret
.active:
mov  rdi, [rsi+0x788]
jmp  0x7032A0

Phase 146 MercGenerateWARs2 -- vtable=0x22BEC98 -- execute sub_C60360 (16 bytes). Second WAR-hazard pass. Identical instruction body to phase 144 (same sub_6FC240 tail-call, same bit-7 gate); the two invocations bracket phase 145 (Opex) which may rewrite operand banks and thereby introduce new write-to-read distances that need re-annotation. Opcode bytes are byte-for-byte identical to phase 144 modulo the vtable store before it.

cmpb [rsi+0x570], 0
js   .active
repz ret
.active:
mov  rdi, [rsi+0x788]
jmp  0x6FC240                  ; same entry as phase 144

Phase 147 MercGenerateSassUCode -- vtable=0x22BECC0 -- execute sub_C603A0 (16 bytes). The terminal Mercury stage: walks the fully-annotated Mercury node list and emits the final SASS binary microcode bytes that will end up in the ELF .text section. Gated by ctx+0x571 bit 0 (the lowest bit of the second flag byte). Tail-calls sub_6EEE90 (1472 bytes), which is a thin wrapper that allocates a 0x110-byte stack scratch area, invokes sub_6E8EB0 for per-function setup, then calls into sub_6E4110 (24 KB, the real emitter documented in Mercury Stage 5).

testb [rsi+0x571], 0x1
jnz  .active
repz ret
.active:
mov  rdi, [rsi+0x788]
jmp  0x6EEE90                  ; MercGenerateSassUCode::Run

Phase 148 ComputeVCallRegUse -- vtable=0x22BECE8 -- execute sub_C5E160 (13 bytes). Computes register usage at virtual call sites (indirect calls, function pointers) and stores the result in the target-side register-use tracker. The data is consumed during ELF emission as EIATTR_EXTERNS/EIATTR_INDIRECT_BRANCH_TARGETS metadata so that the CUDA runtime can honour conservative register budgets for callees whose register footprint is unknown at compile time. Unconditional; all architectures route through the target vtable slot 0x2B8.

mov  rdi, [rsi+0x630]           ; target
mov  rax, [rdi]                 ; vtable
jmp  [rax+0x2B8]                ; target->ComputeVCallRegUse(target)

Phase 149 CalcRegisterMap -- vtable=0x22BED10 -- execute sub_C603C0 (32 bytes). Computes the final physical-to-logical register mapping that gets emitted as EIATTR_REGCOUNT / EIATTR_MIN_STACK_SIZE metadata. The mapping is needed by the CUDA driver to inflate saved contexts during preemption and by NVRTC for relocation. Gated by ctx+0x590 bit 1 (register-map-export knob). Indirects through ctx.target->tex_or_fat_target at ctx+0x630 ; [rax+0x18] then tail-calls sub_95A350 (6456 bytes, the actual mapping builder).

testb [rsi+0x590], 0x2
jnz  .active
repz ret
.active:
mov  rax, [rsi+0x630]
mov  rdi, [rax+0x18]            ; target.sub_target (sm-specific)
jmp  0x95A350                   ; CalcRegisterMap body

Phase 150 UpdateAfterPostRegAlloc -- vtable=0x22BED38 -- execute nullsub_630 at 0xC5E110 (2 bytes, repz ret). True no-op in release ptxas. isNoOp() returns 1 (sub_C5E130, 6 bytes) to suppress the diagnostic frame around the call. The phase slot is kept for ABI compatibility with debug builds where the body is PhaseManager::RebuildAfterPostRegAlloc, but the release build strips it.

Phase 151 ReportFinalMemoryUsage -- vtable=0x22BED60 -- execute nullsub_629 at 0xC5E0E0 (2 bytes, repz ret). True no-op. isNoOp() = 1 (sub_C5E100). Debug builds would dump the memory-arena high-water mark to stderr here; release strips the body entirely.

Phase 152 AdvancedPhaseOriPhaseEncoding -- vtable=0x22BED88 -- execute sub_C5E0B0 (11 bytes). The single surviving late-pipeline gate hook.

movl dword [rsi+0x610], 0x15   ; pipeline_progress = 21
ret

Writes pipeline_progress = 21 (the final value of the monotonic ctx+0x610 counter; see Targets offset +1552). Downstream consumers: sub_8C0270 checks *(ctx+0x610) == 19; scoreboard guards check values 16--19. isNoOp() = 1 (sub_C5E0D0) because the write is state-tracking, not IR transformation.

Phase 153 FormatCodeList -- vtable=0x22BEDB0 -- execute sub_C5E080 (13 bytes). Indirects through a different context object than the other late phases: ctx+0x648 is the code-list / ELF-section emitter rather than ctx+0x630 (target) or ctx+0x788 (Mercury context). Tail-calls vtable+0x10 on that object -- the "format" entry point that serialises the fully-encoded instructions into the final ELF text-section layout (addresses, relocations, alignment).

mov  rdi, [rsi+0x648]           ; code-list emitter
mov  rax, [rdi]                 ; its vtable
jmp  [rax+0x10]                 ; emitter->FormatCodeList()

Phase 154 UpdateAfterFormatCodeList -- vtable=0x22BEDD8 -- execute nullsub_628 at 0xC5E050 (2 bytes, repz ret). True no-op. isNoOp() = 1 (sub_C5E070). Kept as a hook point in case a target backend needs to re-sync IR metadata after FormatCodeList reordered instructions, but no release target uses it.

Phase 155 DumpNVuCodeText -- vtable=0x22BEE00 -- execute sub_C60420 (54 bytes). The gate cascade ctx+0x598 > 0 && ctx+0x740 != NULL && *(ctx+0x740) != NULL is fully retained, so the code path is reachable when the hidden -dump_nvu_code_text=1 knob is set, but the tail-call target 0x67FF60 resolves to nullsub_31 (2 bytes) -- the actual text dumper has been stripped from release ptxas, leaving an orphan gate that falls through to a stub.

mov  eax, [rsi+0x598]           ; verbosity level
test eax, eax
jle  .skip
mov  rax, [rsi+0x740]           ; dump sink
test rax, rax
je   .skip
mov  rdi, [rax]
test rdi, rdi
je   .skip
xor  edx, edx
xor  esi, esi
jmp  0x67FF60                   ; nullsub_31 -- stub
.skip:
repz ret

Phase 156 DumpNVuCodeHex -- vtable=0x22BEE28 -- execute sub_C60460 (~48 bytes). Mirror image of phase 155 with a simpler gate (no extra pointer indirection) and tail-call target 0x67FF50 = nullsub_30. Same conclusion: stripped from release, orphan gate only.

Phase 157 DebuggerBreak -- vtable=0x22BEE50 -- execute nullsub_627 at 0xC5DFE0 (2 bytes, repz ret). Debug-build breakpoint marker; release builds emit a bare ret. isNoOp() = 0 (sub_C5E000), so the diagnostic frame still fires -- useful when running ptxas under gdb with b *0xC5DFE0 because the dispatch loop will print "Before DebuggerBreak" / "After DebuggerBreak" on either side of the breakpoint.

Phase 158 NOP -- vtable=0x22BEE78 -- execute nullsub_626 at 0xC5DFB0 (2 bytes, repz ret). Terminal sentinel. The 159-phase dispatch loop (sub_C64F70) iterates a1[0] .. a1[158] and needs a final slot to anchor the loop end; NOP is that anchor. isNoOp() = 0 (sub_C5DFD0), so the final "Before NOP" / "After NOP" prints appear in verbose dumps as the explicit terminator for "All Phases Summary".

Summary of nullsubs (release build). Five of the 20 phases have bodies that are pure ret stubs: 150, 151, 154, 157, 158. Two more (155, 156) have non-trivial gate cascades but their tail-call targets resolve to nullsubs, making them effectively no-ops too. That leaves 13 phases (139--149, 152, 153) that actually transform IR or pipeline state in a release build. Of the 13 active phases, seven are Mercury encoder stages (141--147) gated by ctx+0x570/ctx+0x571 bits -- so on a non-Mercury backend the active count drops to six (139, 140, 148, 149, 152, 153).

No per-SM arch split across these phases. None of the 20 execute bodies contain an sm_version switch on ctx.target[+0x174] at the phase level; the only such check is in phase 139's gate (> 0x3FFF i.e. "sm50-and-up"). All per-generation specialisation happens one level down, inside the target vtable methods each phase tail-calls (Mercury backend for 141--147, target vtable slots 0x148/0x150/0x2B8 for 140/139/148). The pipeline itself is arch-uniform; backends differ only in the methods they plug into the vtables.

The Mercury phases (141--147) are gated by flag bits at ctx+0x570/ctx+0x571, allowing non-Mercury backends to selectively disable encoding stages. WAR generation runs in two passes (144, 146) bracketing Opex (145) because Opex can rewrite operand banks and thereby introduce new write-to-read distances that need re-annotation -- phase 143 (MercExpandInstructions) also runs before the pair but has its own bit-5 gate.

Pipeline Ordering Notes

Stage numbering. The 10 stages on this page (Stage 1--10) subdivide the 159-phase OCG pipeline. They are distinct from the 6 timed phases in Pipeline Overview (Parse, CompileUnitSetup, DAGgen, OCG, ELF, DebugInfo), which cover the entire program lifecycle. All 10 stages here fall within the single OCG timed phase.

Identity ordering. The default ordering table at 0x22BEEA0 (159 x uint32) is an identity mapping for indices 0--156: exec[N] = factory[N]. The last two entries are zero: exec[157] = 0 and exec[158] = 0, mapping both slots back to factory index 0 instead of the expected 157 and 158. This is benign -- phase 157 (DebuggerBreak, empty body in release builds) and phase 158 (NOP, terminal sentinel) both have trivial execute() bodies, so the factory index they resolve through is irrelevant to pipeline behavior. For all practical purposes the factory index IS the execution order: phases execute in strict index order 0--158, and the two trailing zeros are don't-care slots. The original wiki analysis that placed phases 132--138 as "out-of-order slots" was based on a compressed 139-phase model that excluded 20 phases (see note below).

Repeated passes. Several transformations run at multiple pipeline positions because intervening passes expose new opportunities:

Cross-References

• Optimization Pipeline -- pipeline infrastructure, PhaseManager data structures, dispatch loop
• Phase Manager Infrastructure -- PhaseManager object layout, constructor, destructor, factory switch
• GeneralOptimize Bundles -- sub-pass decomposition of compound optimization passes
• Branch & Switch Optimization -- phases 14, 15, 30, 38
• Loop Passes -- phases 18, 22, 24, 35, 59, 66, 79, 88
• Strength Reduction -- phase 21
• Copy Propagation & CSE -- phases 49, 50, 64, 83
• Predication -- phase 63
• Rematerialization -- phases 28, 54, 69
• Liveness Analysis -- phases 10, 16, 19, 33, 61, 84
• Synchronization & Barriers -- phases 25, 26, 42, 71, 72, 99, 100, 114
• Hot/Cold Partitioning -- phases 41, 108, 109
• GMMA/WGMMA Pipeline -- phases 85, 87
• Uniform Register Optimization -- phases 11, 27, 74, 86
• Late Expansion & Legalization -- phases 5, 45, 55, 78, 93, 137
• Register Allocator Architecture -- phases 101, 103, 105, 123, 124, 138, 148, 149
• Scheduler Architecture -- phases 90, 97--100, 110
• Scoreboards & Dependency Barriers -- phases 114, 115, 116
• Mercury Encoder -- phases 113, 117--122, 141--147, 153
• Optimization Levels -- O-level gating of gate passes
• DUMPIR & NamedPhases -- user-specified phase targeting and reordering

Key Functions