LLVM Patch Catalog

Index page. This is a one-row-per-component summary of every upstream LLVM file that cicc v13.0 carries, classified by patch class. For the underlying analysis, follow the Wiki page column to the per-pass deep dive. For the orchestration that schedules these components, see Pipeline & Ordering.

CICC v13.0 statically links a fork of LLVM 20.0.0. Some files are byte-for-byte upstream; some carry GPU-specific threshold overrides registered as new cl::opt knobs; some are recognizably upstream but have algorithmic additions tied to the GPU execution model; and a handful are fully proprietary with no upstream counterpart. This page enumerates every component covered by the LLVM Passes section of the wiki and labels each.

Patch Classes

Within the tables below, rows are grouped by upstream LLVM directory (the layout reimplementers will most naturally use when porting). Each row points at the dedicated wiki page where the delta is documented in detail. The "Upstream file" column refers to LLVM 20.0.0 unless otherwise noted.

Provenance Signals

A row's patch class is assigned by combining four signals visible in the binary:

1. Symbol-level fingerprints. Function lengths, hash-table sizes, switch case counts, and constructor patterns line up against the same compilation of LLVM 20.0.0. A function whose disassembly walks the same case labels in the same order as the upstream .cpp (read alongside the wiki deep-dive) is none or config-only. A function that emits extra basic blocks before joining the upstream control flow is algorithmic. A function that shares only the entry-point name with upstream is proprietary fork.
2. Knob inventory. cl::opt<...> constructors (ctor_NNN symbols at fixed addresses) register the cicc-side tunables. Knobs whose names match upstream verbatim and whose defaults match upstream constants are config-only signals. Knobs whose names are NVIDIA-prefixed (nv-*, nvvm-*) or whose registrar uses NVIDIA-specific calling conventions (sub_190BE40's int** default initializer) are algorithmic signals.
3. Pipeline placement. A pass that is scheduled multiple times, at non-upstream pipeline positions, or under cicc's tier system (Tier 0/1/2/3 in sub_12E54A0) carries scheduling-level customization even when the per-pass binary is stock.
4. Companion NVIDIA-only symbols. Where the cicc pipeline calls a stock pass and immediately follows it with an NVIDIA-only pass that compensates for what the stock pass cannot do on GPU (the second-pass coalescer after RegisterCoalescer, MRPA after MachineScheduler, the NVPTX-specific block placement after MachineBlockPlacement), the upstream row is labeled none but the companion row appears under the Target / NVPTX table as proprietary fork.

Rows where the binary contains both an unused stock upstream copy and an active NVIDIA copy (StructurizeCFG, LSR, the dual RAGreedy instances) are labeled by the active copy. See the quirks at the bottom of the page for why both copies coexist.

Pipeline & Infrastructure

Analysis

Transforms / Scalar

Transforms / Loop

CodeGen / Machine-Level (Target-Independent)

Target / NVPTX

Summary Counts

(Counts include both upstream files and the small set of NVIDIA-only entries documented under their nearest-upstream sibling.)

Quirks of the Classification

QUIRK -- "Stock" sometimes means two copies side-by-side. Several passes that classify as none or config-only (notably StructurizeCFG, MachineBlockPlacement, RegisterCoalescer, and LoopStrengthReduce) ship as two distinct symbols in the binary: the upstream copy that arrives from linking against libLLVMCodeGen/libLLVMScalarOpts and a separate NVIDIA copy that the cicc pipeline actually invokes. The unused upstream copy is dead code from the pipeline's perspective but cannot be stripped because other components in the binary still link the upstream symbol. Reimplementers should not be misled by sizeof-binary into thinking these are heavily modified — the modification is in which copy gets scheduled, not in the algorithm of either copy.

QUIRK -- LTO inlining inflates apparent patch class. LegalizeTypes is labeled algorithmic because all four upstream files (LegalizeTypes.cpp, LegalizeIntegerTypes.cpp, LegalizeFloatTypes.cpp, LegalizeVectorTypes.cpp) collapse into a single 348 KB function. The functional behavior is a faithful reproduction of upstream DAGTypeLegalizer; the structural shape is the only delta. Likewise, InstCombine's ~15 upstream files inline into one 405 KB visitor. A faithful reimplementation can keep the upstream file split — the monolithic shape is a build-system artifact, not a behavioral requirement.

QUIRK -- "config-only" hides materially different schedules. A pass classified config-only (e.g. SROA, LICM) may still produce dramatically different output from a stock LLVM 20 invocation because cicc runs it more than once and at different pipeline positions. SROA runs twice (early after NVVMReflect, late after sinking); LICM runs early (hoist) plus late (sink); LoopRotate appears at several canonicalization points. The pass binary is upstream, but the scheduled effect is GPU-tuned. The full ordering lives in Pipeline & Ordering.

How to Use This Catalog

For a reimplementer porting cicc to an open LLVM base, the patch class maps directly to the work effort:

• none rows: link the matching upstream .cpp unchanged. Re-apply scheduling from Pipeline & Ordering.
• config-only rows: link upstream and re-register the cicc knobs and their defaults. Wire into the same pipeline slots.
• algorithmic rows: start from upstream, then port the NVIDIA-specific extensions documented on the linked wiki page. Expect roughly one fork patch per row.
• proprietary fork rows: build from the wiki deep dive. Upstream provides only the registration interface and surrounding infrastructure; the algorithm itself comes from the binary analysis.

For the inverse view — pipeline slot to pass list — see Pipeline & Ordering. For NVIDIA-only passes that do not appear in this catalog at all (because they have no upstream counterpart even at the file level), see NVIDIA Custom Passes.

Suggested Porting Order

A reimplementation that follows the binary's optimization order rather than the upstream LLVM source order tends to surface fewer surprises:

1. Start with the none rows — link upstream, confirm the cicc pipeline assembler will accept them, and lock in the registration names.
2. Layer in the config-only rows. The knob defaults live in the cicc constructors documented on each deep-dive page; mismatched defaults are the most common cause of "the pass runs but the output is different" bugs during porting.
3. Port the algorithmic rows next, one wiki page at a time. The deep-dive pages enumerate the NVIDIA additions as discrete patches against the upstream .cpp; each can be applied and tested independently.
4. Tackle the proprietary fork rows last. These have the longest implementation tail (LSR alone is 2,688 decompiled lines; the SelectionDAG intrinsic switch is 9,518) and benefit from the surrounding infrastructure being already in place when their tests run.

Where the Catalog is Deliberately Incomplete

This catalog covers the LLVM-derived components only. Three classes of cicc functionality are intentionally absent:

• NVIDIA-only IR passes (Memory Space Opt, NVVM Reflect, Printf Lowering, the process-restrict family, etc.) live under NVIDIA Custom Passes. They have no upstream file to point at.
• The EDG frontend that feeds the LLVM pipeline (NVVM IR generation, builtin lowering at sub_955A70) is documented under Pipeline Overview and is not derived from LLVM at all.
• PTX emission (the AsmPrinter at sub_21E74C0 and the surrounding text-writer infrastructure) is heavily NVIDIA-customized but classifying it row-by-row would require enumerating every PTX directive; the Pipeline / Emission page covers it as one unit.

Together this catalog plus the NVIDIA Custom Passes Overview cover the full optimization-and-codegen surface of cicc v13.0.