Internal Pass-Name Catalog

All addresses and offsets on this page apply to libtpu.so from the libtpu-0.0.40-cp314 wheel (libtpu_lts_20260413_b_RC00, build-id md5 89edbbe81c5b328a958fe628a9f2207d, 781,691,048 bytes, ELF x86-64 DYN, not stripped, clang/LLVM trunk). The image carries its full C++ symbol table, so the pass names below are demangled name()/getArgument() symbols and verbatim .rodata strings, not inferred labels. Other wheels will differ.

Abstract

This page is the name index of every internal compiler pass libtpu registers — the verbatim identifier each pass returns from xla::HloPassInterface::name(), the -flag argument an mlir::Pass registers with the MLIR PassRegistry, and the capitalized stage string an xla::HloPassPipeline carries in its constructor. It is a reference catalog, not an algorithm page: its value is the grouped, deduplicated table of names cross-linked to the Part-V compiler pages that document each pass body. Where hlo-pass-registry.md explains how passes are added and ordered, this page answers "what is this string I just saw in a VLOG, an xla_dump directory, or a --pass-pipeline= spec, and which page documents it?"

Because the image is unstripped, the names are recovered with near-1:1 fidelity by two complementary symbol enumerations rather than by disassembly. The HLO surface comes from the _ZNK3xla*4nameEv symbol set — every XLA HLO pass overrides HloPassInterface::name(), so demangling those symbols enumerates the registered HLO passes directly; 322 of them are real passes across three provenance tiers. The MLIR surface comes from the create*Pass / Create*Pass factory symbols plus the getArgument() pass-flag strings; it splits cleanly by dialect (StableHLO/CHLO/VHLO, Shardy, XTile, tpu, mosaic_sc, sparse_core, llo) and is capped at the bottom by the 242 tpu-* LLVM-backend MachineFunction pass flags. A handful of capitalized HloPassPipeline stage strings and a phaseN_* separate-compilation metric taxonomy round out the inventory.

The two name() spellings a reader will meet differ by convention. An HLO pass's runtime name is the kebab-case of its class (ShardingPropagation → sharding-propagation); ~25 of these are byte-confirmed as literal strings, the rest are built at runtime and are inferred from the class name (marked INFER below). An MLIR pass's name is the literal it hands to mlir::PassRegistration and is byte-confirmed wherever its getArgument() symbol carries the string. The page groups names by pipeline phase — HLO-opt, sharding/SPMD, layout, fusion, collective, scheduling, MSA, host-offload, SparseCore, then the MLIR lowering cascade and the LLVM-backend codegen tail — and gives, per group, the documenting wiki page. Status/error templates are on error-templates.md; advisory hint strings on hint-strings.md; this page owns only the pass-name index and the name→page cross-link.

The catalog contract:

• The four name families and how each is recovered (name() RTTI · create*Pass factory · getArgument() flag · pipeline stage string).
• Per phase: the verbatim registered name, its provenance tier (T TPU-private / O open-source XLA), and a confidence tag (byte-confirmed string vs convention-inferred).
• The name → documenting-page cross-link for every group that has an owning Part-V page.
• The honest gap: ~300 HLO name() strings are convention-inferred, the per-pass add order is owned by the registry pages, and the flag→pass gating is not on this page.

NOTE — the counts are name-complete for the symbol families (HLO name(), create*Pass, getArgument()) and string-confirmed for the pipeline stages. The add order of any pass inside any pipeline is not on this page — it is owned by hlo-pass-registry.md and the per-phase registry. This is the name index; the order index is the registry.

How the Names Are Recovered

Four name families, four extraction surfaces. The provenance matters because it sets the confidence: a demangled symbol is CERTAIN for the class, while the runtime string it returns is only CERTAIN when the literal is also present in .rodata.

HLO pass name      ── _ZNK3xla*4nameEv symbol  ── kebab(ClassName)         ── string CERTAIN iff literal in .rodata, else INFER
MLIR pass flag     ── create*Pass / Create*Pass factory symbol             ── string CERTAIN where getArgument() carries it
MLIR pass flag     ── PassIN…getArgumentEv symbol body                     ── byte-confirmed literal
pipeline stage     ── HloPassPipeline ctor std::string at a .rodata offset ── byte-confirmed literal
phaseN_* metric    ── .rodata token referenced from RegisterAllPhases      ── byte-confirmed literal

The confidence convention used in every table:

Tier column: T = TPU-private (xla::jellyfish::*, xla::tpu::sparse_core::*, xla::Tpu*, xla::megascale::*) — the Deepsea/Jellyfish backend's private surface; O = open-source XLA (xla::*), shared with the CPU/GPU backends.

QUIRK — an HLO pass's registered name is the kebab-case of the class, not of the file or the factory. xla::jellyfish::TpuInt2AutoUpDownCaster registers tpu-int2-auto-up-down-caster — the Tpu prefix survives, the namespace does not. A reimplementer who derives the name from the source filename (tpu_int2_caster.cc) or the namespace path will mismatch every VLOG/xla_dump filter.

HLO Pass Names

The HLO surface is 322 passes across three provenance tiers: 137 xla::jellyfish::* (TPU-private), 24 xla::tpu::sparse_core::* (SparseCore-HLO), 161 open-source xla::*, plus ~6 megascale/sdy/spmd/conditional_opt. Grouped below by the pipeline phase that adds them. Names are the kebab-case the class returns from name(); the string is CERTAIN only where a literal was located, else INFER.

HLO-Opt — expanders / canonicalizers / simplifiers (Phase 1)

The input-scrub phase: lower high-level ops to primitive arithmetic, canonicalize shapes and conditionals, fold constants, and run the algebraic simplifier. Documented on hlo-pre-passes.md; the simplifier itself on algebraic-simplifier.md.

NOTE — the jellyfish::Tpu* rewriters are supersets of the OSS pass of the same root name, not replacements; TpuAlgebraicSimplifier re-runs the OSS AlgebraicSimplifier rule set plus TPU-only rules. Both classes have a distinct name() symbol, so a VLOG filter sees two strings.

Sharding / SPMD / Partition (Phase 2-3)

Sharding propagation and SPMD partitioning. sharding-propagation is byte-confirmed (literal appears three times — once per registration in the propagation, dump, and verifier paths). Documented on sharding-propagation.md and auto-sharding-spmd.md.

Layout / Tiling / Memory-Space (Phase 4-5)

Layout assignment, TPU tiling propagation, and memory-space propagation. Documented on layout-assignment.md.

Fusion (Phases "Pre main fusion" / "Main fusion" / "Post main fusion")

The fusion bucket. tpu-instruction-fusion (the main pass, using TpuPriorityFusionQueue) builds its name at runtime — the class symbol xla::jellyfish::TpuInstructionFusion::name() is present at 0x12e037a0 but carries no .rodata literal, so the name is HIGH-confidence by convention. Documented on fusion-patterns.md and fusion-cost-model.md.

Collective / Async Rewriting (Phase 4 onward)

All-reduce / all-gather / reduce-scatter / all-to-all combiners, legalizers, and async-collective creators, including the MegaScale cross-slice family. Not individually paged; this is the name index.

Scheduling (Phase 7: "final_scheduler" / "async_scheduling")

The latency-hiding scheduler family. Three scheduler name() strings are byte-confirmed dashed literals — latency-hiding-layer-scheduler, sparsecore-latency-hiding-scheduler, and legalize-scheduling-annotations (one hit each). The OSS latency-hiding-scheduler name is built at runtime: only the substring latency-hiding-scheduler inside the two TPU-prefixed forms is present in .rodata, so that row is HIGH, not CERTAIN. The scheduler placement is owned by hlo-pass-registry.md.

QUIRK — final_scheduler and async_scheduling are pipeline stage names, not pass names — they are the HloPassPipeline constructor strings for the two scheduler pipelines, and they live in the pipeline-stage section below. The passes inside those pipelines are the *-scheduler rows above. Do not confuse the pipeline label with the pass it contains.

MSA — Memory-Space Assignment (after scheduling)

MSA is one engine, not a HloPass with a name(); it is driven by xla::jellyfish::RunMemorySpaceAssignment. Documented on msa-overview.md.

Host-Offload (Phase 5-6)

Host-offload analysis and asyncification. Not individually paged.

While-Loop / Pipelining / Misc

While-loop simplification, unrolling, rematerialization, and assorted TPU rewrites. Loop transforms documented on loop-tiling-unrolling.md; opt-barrier handling on optimization-barrier.md.

SparseCore-Offload (HLO-level)

The HLO-level SparseCore offloaders that run before the SparseCore MLIR lowering. The 24 xla::tpu::sparse_core::* HLO passes (embedding / sparse-dense matmul decomposers) are the SparseCore-HLO tier; the MLIR tile-task passes are in the SparseCore MLIR section. Documented on lower-to-sparsecore-llvm.md.

MLIR Pass Names

The MLIR surface is recovered from create*Pass/Create*Pass factory symbols and getArgument() pass-flag literals. It splits by dialect and forms a 4-stage lowering cascade. Names below are the getArgument() literal (byte-confirmed where a getArgument() symbol carries it).

StableHLO ── createStablehloLowerToXtilePass ──> XTile
XTile     ── vector-layout / tiling passes     ──> tpu (TensorCore vector IR)
tpu       ── createLowerToLLOPass              ──> LLO ── tpu-bundle-packer / tpu-encode-mcinst-bundles ──> ISA bundles
tpu       ── (SparseCore fork) sc 36 passes    ──> Mlo ── createLowerToSparseCoreLlvmPass ──> LLVM-TPU IR

StableHLO / CHLO / VHLO Legalizers

Input wire-format legalization. Documented on mhlo-xtile-tpu-lowering.md.

Shardy (sdy) Round-Trip Sharding

The Shardy import/export round-trip. Documented on sharding-propagation.md.

XTile

The StableHLO → XTile lowering layer, plus the XTile-CPU bufferization/vectorization passes. Documented on mhlo-xtile-tpu-lowering.md.

tpu Dialect — TensorCore Vector IR (14 create*Pass)

The TensorCore vector-layout and lowering passes. lower-to-llo and lower-to-mlo are byte-confirmed (getArgument() literals located). Documented on tpu-dialect-and-ops.md and tpu-to-llo-ods.md.

mosaic_sc Dialect — Mosaic-for-SparseCore (3 create*Pass)

Documented on mosaic-overview.md.

SparseCore Tile-Task Passes (36 Create*Pass)

The xla::tpu::sparse_core::Create*Pass family — the SparseCore tile-task lowering chain (bounds-checks, tile outlining, allocation, prefetch scheduling, LLVM lowering). Documented on lower-to-sparsecore-llvm.md. Named by function rather than dumped flat:

llo / LLO Bridge

The LLO-extension elimination pass that closes the MLIR cascade before bundle packing. Documented on lower-to-mlo-dma-bridge.md and llvmtpu-intrinsic-catalog.md.

TPU LLVM-Backend MachineFunction Pass Flags (242)

The bottom of the codegen stack, below LLO: the TPU LLVM target's machine-level passes, exposed as 242 tpu-* cl::opt flag strings. Only the flag strings are recovered — the llvm::Pass subclass symbols behind them are not on this page (codegen tail). Grouped by function rather than dumped flat:

GOTCHA — several tpu-* strings are dual-surface: tpu-call-inliner, tpu-instruction-fusion, tpu-int2-auto-up-down-caster, tpu-tiling-propagation, tpu-partition-assignment appear both as HLO name() strings (above) and as tpu-* flag args here. They are the same logical pass exposed at two registry levels. Counting the tpu-* flags and the HLO name() strings as disjoint sets double-counts these; treat the HLO-level pass as canonical and the flag as its CLI alias.

Pipeline-Stage Names

Two phase taxonomies coexist. The monolithic compile labels its HloPassPipeline stages with capitalized strings (the std::string passed to the pipeline constructor); the separate compile (tpu_phase_functions.cc) labels its phases with phaseN_* metric tokens. They are not interchangeable. Both documented on compile-phases.md.

Monolithic HloPassPipeline Stage Strings

Separate-Compilation Phase Metric Tokens

The multi-phase compile names its phases with phaseN_* tokens (the metric keys in the separate-compilation timing table). phase1_hlo_opts and phase3_linking are byte-confirmed as literals referenced from xla::TpuCompiler::RegisterAllPhases @ 0xf849ec0. "TLP" = TPU-Level-Program.

NOTE — the phaseN_* tokens are metric keys, not pass names — they appear in timing/transfer tables, never as a pass a reader can run. A VLOG or xla_dump filter will match the stage strings above and the pass names earlier; it will not match phaseN_* unless reading the separate-compilation timing path. The RegisterAllPhases symbol that anchors phase1_hlo_opts/phase3_linking is the registration entry, not a per-phase pass body.

Not Confirmed / Not on This Page

Honest scope limits, so a reimplementer knows what to re-derive:

• ~300 HLO name() strings are convention-inferred (INFER), not byte-confirmed. The name() body builds the string at runtime (a static const or a string-builder); only ~25 dashed names are present as literals in .rodata (the CERTAIN rows). The class symbol is certain; the exact returned string follows the CamelCase→kebab convention but was not located per pass.
• The add order of each pass is not here. This is the name index; the order is owned by hlo-pass-registry.md (Phase-1..6 sequence), the scheduler placement, and the fusion-bucket order.
• The flag → pass gating is not here. Which xla_tpu_* flag enables which AddPass<T> is a .text branch in RunHloPasses (0x1093a420), not a string this page recovers.
• The 242 tpu-* flags' llvm::Pass class symbols are not recovered — only the cl::opt flag strings.
• The per-TpuVersion (jxc/pxc/vxc/glc/gfc) pass-set delta is not isolated — the HAL modules are named per version, but which passes are skipped for v3 vs v6e is a Target::tpu_version() branch not traced here.

Cross-References

• hlo-pass-registry.md — the pass-add registry; this page is its name index, that page is its order index
• compile-phases.md — the monolithic-vs-separate phase taxonomy that the stage strings label
• algebraic-simplifier.md — body of the algebraic-simplifier / TpuAlgebraicSimplifier rows
• sharding-propagation.md — body of sharding-propagation (byte-confirmed ×3) and the sdy round-trip passes
• auto-sharding-spmd.md — body of the auto-sharding / tpu-spmd-partitioning rows
• layout-assignment.md — body of the layout-assignment / tpu-tiling-propagation rows
• fusion-patterns.md — body of tpu-instruction-fusion and the fusion bucket
• loop-tiling-unrolling.md — body of the while-loop unroll / pipeline rows
• optimization-barrier.md — body of the optimization-barrier-expander row
• msa-overview.md — the MSA engine behind the memory-space rows
• mhlo-xtile-tpu-lowering.md — the StableHLO/XTile/tpu MLIR lowering cascade
• lower-to-sparsecore-llvm.md — the 36 SparseCore Create*Pass lowering chain
• tpu-to-llo-ods.md — the lower-to-llo / lower-to-mlo bodies
• error-templates.md — the error/status template catalog (contrast: this page owns pass names, not error text)
• hint-strings.md — the advisory-hint catalog (contrast: this page owns pass names, not remedies)
• overview.md — Part XI runtime section map