Proposal: package-level parallel LLVM compilation

[zhouguangyuan0718]

Summary

Enable bounded package-level parallel compilation for LLGo's expensive LLVM backend while preserving the existing frontend, cache, runtime-selection, archive, dead-code, and link semantics.

The central rule is:

Finish all mutable Go-side preparation before starting LLVM workers. Share that prepared state read-only, but give every worker its own LLVM-owned state.

The effective worker bound is Go's -p value. When -p is not specified, LLGo uses GOMAXPROCS. Go SSA construction and isolated LLVM backends both use this bound, in two separate phases. LLVM backend packages do not wait for their import dependencies once Go SSA and shared metadata preparation have completed.

This issue documents the architecture already split across merged prerequisites and the open implementation stack, records the current compatibility boundary, and defines the remaining validation and follow-up work.

Motivation

Large LLGo builds spend most of their wall time in per-package LLVM lowering, optimization, code generation, and archive production. The former build loop processed every package serially even though, after Go SSA construction and frontend metadata discovery, most package LLVM modules are independent.

Simply putting the former buildOne call in goroutines is unsafe. A single LLGo ssa.Program owns an LLVM Context, TargetMachine, Go-to-LLVM type caches, ABI state, symbol maps, package syntax/locality state, callbacks, and link-time package modules. Several of those were also affected by process-global configuration in the old entry path.

The implementation therefore separates three concerns:

1. invocation and frontend state isolation;
2. coordinator preparation of immutable Go-side information;
3. independent LLVM backend sessions scheduled by bounded workers.

Proposed build flow

flowchart TD
    A["Build invocation<br/>clone Config; capture cwd and env"] --> B["Load packages and source patches"]
    B --> C["Prepare shared Go metadata<br/>syntax, linknames, exports, localities,<br/>closure env, nointerface, type backgrounds"]
    C --> D{{"Parallel Go SSA build<br/>up to effective -p"}}
    D --> E["Serial SSA order repair"]
    E --> F["Precompute caller tracking<br/>for all SSA packages"]
    F --> G["Serial package preflight<br/>fingerprint/cache, SFiles, Plan 9 policy,<br/>backend classification; then freeze inputs"]

    G --> H{"Backend class"}
    H -->|"patched package"| I["Coordinator backend + archive publish"]
    H -->|"Plan 9 asm, non-exe,<br/>ModeGen, or ModuleHook"| J["Coordinator backend + archive publish"]
    H -->|"ordinary executable package"| K{{"Isolated backend workers<br/>up to effective -p"}}

    K --> L["Fresh llssa.Program<br/>LLVM Context and TargetMachine"]
    L --> M["Fresh lowering/type caches,<br/>ABI state and C ABI transformer"]
    M --> N["LLVM lowering, passes and codegen"]
    N --> O["Write package archive and cache<br/>immediately in the same task"]
    O --> P["Retain successful Program + LPkg<br/>until whole-program consumers finish"]

    I --> Q["Join package results"]
    J --> Q
    P --> Q
    Q --> R["Serial link, method DCE,<br/>strong ABI overrides and finalization"]
    R --> S["Clear LPkg and explicitly Dispose<br/>all retained worker Programs"]

Loading

Normal packages are processed first. Their NeedRuntime and NeedPyInit results decide whether the runtime package group is activated, preserving the existing delayed runtime behavior. Packages are independent within each activated backend group; there is no LLVM import-dependency DAG.

Archive and cache publication is part of the package backend task. This avoids a separate publication wave and lets I/O start as soon as each package finishes code generation.

State ownership

State	Ownership and lifetime
LLVM executable discovery / PATH	Process background, established once before build.Do; never changed by package workers.
Invocation Config, cwd, environment	Cloned or captured once per invocation and passed explicitly.
Frontend options	Invocation-owned cl.Options; no process-wide debug/frontend switches or global lock.
Go packages, AST/type identity, Go SSA program	Coordinator-owned. Go SSA packages are built in parallel, then treated as prepared input to the backend phase.
Package syntax metadata	Linknames, exports, closure-env directives, nointerface markers, type backgrounds, parsed syntax identity, and locality metadata are fully prepared before backend sessions and then shared read-only.
Caller tracking	Precomputed once for every Go SSA package before backend workers start; workers only query it.
Fingerprints, cache decisions, SFiles and Plan 9 policy	Resolved on the coordinator during package preflight. SFiles are frozen before workers.
Backend llssa.Program	One per isolated package; owns a fresh LLVM Context, TargetMachine/TargetData, lowering caches, type maps, ABI maps, and module.
C ABI transformer	One per backend Program; never shared across workers.
Archive/cache publication	Runs immediately after successful codegen inside the same package task. LLVM object bytes are archived directly from MemoryBuffer; file-backed cgo/Plan 9 members are included without first spilling the LLVM object to a temporary .o.
Successful LPkg and worker Program	Transferred to the coordinator and retained through link-time DCE and ABI consumers, then explicitly released on normal, error, and panic paths.

There is intentionally no global worker lock, environment snapshot/restore wrapper, syntax delta merge, syntax validation pass, or PackageSummary prerequisite in the current design.

Parallelism and scheduling

• -p=N sets the maximum number of package workers.
• With no explicit -p, the default is GOMAXPROCS.
• Go SSA construction is bounded by this value.
• Isolated LLVM backend tasks are also bounded by this value.
• The two worker phases are currently separated by SSA order repair, caller-tracking precomputation, and package preflight; this proposal does not pipeline SSA directly into LLVM.
• LLVM packages are submitted as a flat set after preflight. Import dependencies do not constrain LLVM scheduling because their Go SSA and shared frontend metadata already exist.
• Worker errors are collected concurrently but reported in deterministic package input order.
• Patched and coordinator-only packages remain serial and do not overlap isolated workers in the current implementation.

Compatibility boundary

The coordinator path remains the fallback for:

• patched/alternate lowering that must use the coordinator Program;
• packages using selected Plan 9 assembly;
• non-executable build modes;
• ModeGen;
• builds with ModuleHook.

Cache hits retain the old link semantics: LLGo reconstructs the frontend module required by whole-program consumers, skips backend emission, and keeps the resulting live package state through linking. This is why the implementation cannot yet destroy every worker Program immediately after archive publication.

PR #1736 adds link-time method dead-code analysis that consumes live package modules. Until that information is moved into a Go-owned summary, successful worker Programs must remain alive through linkMainPkg. Cross-context DCE constants and strong ABI types must be recreated in the destination LLVM Context; LLVM values must never cross Context boundaries directly.

Build scheduler trace

PR #2243 adds:

llgo build -debug-trace=/path/to/trace.json ...

The output uses Chrome Trace Event JSON and opens directly in chrome://tracing or Perfetto. It records:

• package loading and shared-state preparation;
• parallel Go SSA tasks;
• serial SSA order repair and caller-tracking precomputation;
• per-package preflight/cache decisions;
• patched, coordinator, and isolated backend classifications;
• backend plus immediate archive/cache publication;
• direct SSA-to-backend flow edges;
• final serial linking.

Worker lanes use the same effective -p bound as the build. The trace target is created exclusively, so an existing source, build file, or previous trace is not silently overwritten. A trace flush failure is reported as a warning and does not turn a successful compilation into a failed build.

Actual etcd trace

Measured on go.etcd.io/etcd/server/v3 at etcd commit 3e3b4c181c69, with LLGo build cache disabled and all package compilation forced:

LLGO_BUILD_CACHE=off llgo build -a -p=8 \
  -debug-trace=/tmp/etcd-p8.json \
  -o /tmp/etcd ./server

Trace observation	Result
Wall time with trace	52.36 s
Go SSA tasks	592
Go SSA peak parallelism / phase window	8 / 0.40 s
Caller-tracking precomputation	14.14 s serial
Package preflight	1.56 s serial
Patched backends	11 tasks / 2.58 s serial
Other coordinator backends	11 tasks / 0.89 s serial
Isolated LLVM backends	553 tasks
Isolated backend peak / average parallelism	8 / 7.19
Time at all 8 isolated workers active	82.3% of the isolated window
Isolated backend work / elapsed window	156.41 CPU-task s / 21.75 s
Complete backend phase	25.22 s
Final link	8.37 s serial

The trace shows that the expensive LLVM region is genuinely package-parallel and mostly saturates the requested bound. It also exposes the next large serial targets: caller tracking and final link.

Without trace, three forced etcd builds averaged 134.40 s at p=1 and 53.26 s at p=8, a 2.52x wall-time speedup. CPU time increased by about 27.9%, and peak RSS increased from about 7.19 GB to 7.40 GB. Kubernetes kubeadm previously improved from 439.31 s to 254.85 s (1.72x) under the same no-package-output-cache methodology.

Repeated p=1/p=8 builds with the same output path produced identical binaries. Builds written to different paths differ only in Mach-O UUID and ad-hoc code-signature metadata, not executable code or data.

PR map

Merged prerequisites

• build: isolate invocation configuration and execution #2212 — isolate invocation configuration/execution; clone Config; capture cwd/environment once; keep LLVM tool discovery process-scoped and stop mutating process state during builds.
• compiler: always use main symbol prefix #2246 — make main symbol prefix unconditional and remove the mutable RewriteMainPrefix policy.
• compiler: isolate per-invocation frontend state #2221 — make frontend options invocation-local and remove process-wide frontend debug switches/locks.
• build: Go Linktime-like Unreachable Method Pruning #1736 — add link-time method DCE; this establishes the current requirement to retain live worker modules through linking.
• build: split package compilation stages #2175 — split package compilation into preflight, backend, and publication stages; make dependencies/fingerprints explicit; archive LLVM output directly from memory; keep publication attached to its package task.

Open implementation stack

1. ssa: make recursive type conversion order-independent #2280 — make mutually recursive Go-to-LLVM type conversion order-independent, so independent backend Programs cannot produce order-dependent placeholders.
2. build: prepare read-only package backend state #2282 — prepare package metadata once, share it read-only, and create fresh backend Programs without snapshot/overlay/delta machinery.
3. build: run LLVM package backends in parallel #2182 — classify packages, run bounded isolated LLVM workers, publish archives immediately, retain successful Programs through link, and release them deterministically.
4. build: add Chrome scheduler trace #2243 — add the Chrome/Perfetto build scheduler trace on top of build: run LLVM package backends in parallel #2182.

Closed experimental PRs such as the SSA-to-backend pipeline and a separate parallel-publish layer are not part of this proposal. Publication is already in the backend task, and the etcd trace shows only about 0.40 s of Go SSA work versus 14.14 s of caller precomputation and 25.22 s of backend work, so SSA/backend pipelining is not currently the highest-value optimization.

Alternatives considered

Run the old package build loop in goroutines

Rejected because the old loop shared an LLVM Context, TargetMachine, lowering caches, ABI state, package metadata mutation, environment/cwd behavior, and link-time modules.

Schedule LLVM packages by import dependencies

Rejected as unnecessary. Import ordering matters while constructing and preparing Go SSA/frontend state. After that phase, each LLVM package can lower independently; imposing the import DAG would reduce parallelism without adding correctness.

Protect shared backend state with a global lock

Rejected because it would make concurrency mostly cosmetic and would retain process-global coupling between builds.

Parallelize only LLVM pass/codegen inside a shared frontend Program

Rejected for now because creating and lowering the package module already touches LLVM-context-owned type/value state. Safe isolation begins at a complete backend Program, not at a late pass-manager boundary.

Require PackageSummary before enabling workers

Deferred. A complete summary remains useful for reducing retained memory, but it must carry all link-time information consumed by DCE, ABI override generation, method tables, globals, funcinfo/PCLN, C exports, runtime flags, and cache metadata. Retaining live Programs preserves existing semantics and enables parallelism sooner.

Pipeline SSA directly into LLVM

Deferred. It requires incremental caller/dependency preparation or another synchronization boundary. Current trace data shows SSA itself is a very small fraction of the etcd build; optimizing caller tracking and link offers more immediate value.

Risks and mitigations

• Peak memory: multiple LLVM modules remain live through linking. Keep -p bounded and pursue PackageSummary as follow-up work.
• Cross-context LLVM values: recreate types/constants from Go-owned identities and verify every worker module; never pass raw LLVM values between Programs.
• Nondeterminism: keep package/result ordering deterministic, test p=1 versus p=8, and compare output code/data.
• Failure cleanup: worker ownership transfers only after success; coordinator defers clear all LPkg references before disposing Programs on normal, error, and panic paths.
• Fallback behavior: unsupported modes and packages use the unchanged coordinator path rather than partially isolated behavior.
• Observability: keep the scheduler trace build-local and optional; disabled tracing has no shared state or output file.

Validation and acceptance criteria

• Merge the implementation in dependency order: ssa: make recursive type conversion order-independent #2280, build: prepare read-only package backend state #2282, build: run LLVM package backends in parallel #2182, then build: add Chrome scheduler trace #2243.
• Pass focused ssa, cl, internal/build, internal/dcepass, command, and environment tests.
• Pass race tests for concurrent invocations, backend Program sharing, caller tracking, worker scheduling, DCE context cloning, retention, and cleanup.
• Pass full symbol/testdrop validation and LLVM verifier checks.
• Exercise clean and warm package-cache builds at p=1 and p=8.
• Exercise ordinary Go, cgo, Plan 9 assembly, patched runtime packages, LTO, and cache-hit linking.
• Verify deterministic output code/data between serial and parallel builds.
• Benchmark representative large programs and record wall time, user+sys CPU, and peak RSS.
• Keep link and whole-program transformations serial until they have an independently reviewed ownership model.

Follow-up work

1. Reduce or parallelize caller-tracking precomputation, currently 14.14 s in the etcd trace.
2. Define PackageSummary and move link/DCE consumers to Go-owned data so worker LLVM modules can be released earlier.
3. Investigate safe overlap of coordinator-only packages with isolated workers.
4. Re-evaluate Plan 9 assembly parallelism only after measuring a workload where it is material.
5. Use scheduler traces in benchmark/CI investigations to track lane utilization, long-tail packages, and regressions.

[zhouguangyuan0718]

中文版本

以下内容与上方英文 Proposal 的结构和设计边界对应。

概要

在保持现有前端、缓存、运行时选择、归档、死代码分析和链接语义不变的前提下，为 LLGo 耗时较长的 LLVM 后端增加有界的包级并行编译能力。

整个方案的核心原则是：

在启动 LLVM worker 之前，先完成所有会发生修改的 Go 侧信息准备。准备完成的信息只读共享，但每个 worker 必须拥有独立的 LLVM 状态。

worker 数量由 Go 的 -p 参数决定；没有显式传入 -p 时，LLGo 使用 GOMAXPROCS。Go SSA 构建和隔离的 LLVM 后端都使用这一并行上限，但它们目前是前后两个阶段。完成 Go SSA 和共享元数据准备后，各个包的 LLVM 后端不再等待其 import 依赖完成。

本 Proposal 用于记录已经拆分到前置 PR 和当前实现栈中的架构、兼容边界、验证情况以及后续工作。

背景与动机

大型 LLGo 项目的主要构建时间消耗在每个包的 LLVM lowering、优化、代码生成和归档上。此前的构建循环会串行处理所有包；但在 Go SSA 和前端元数据准备完成之后，大多数包的 LLVM Module 实际上可以相互独立地处理。

不能简单地把原来的 buildOne 放进 goroutine。单个 LLGo ssa.Program 同时持有 LLVM Context、TargetMachine、Go 类型到 LLVM 类型的缓存、ABI 状态、符号表、包语法和 locality 信息、回调以及链接阶段仍需使用的包 Module。旧的构建入口中还有一部分状态受到进程全局配置影响。

因此，实现被拆分成三个问题：

1. 隔离每次构建调用和前端配置；
2. 在 coordinator 中提前准备之后只读的 Go 侧信息；
3. 为每个包创建独立 LLVM 后端会话，并通过有界 worker 调度。

构建流程

flowchart TD
    A["构建调用<br/>克隆 Config；捕获 cwd 和 env"] --> B["加载包和 source patch"]
    B --> C["准备共享 Go 元数据<br/>syntax、linkname、export、locality、<br/>closure env、nointerface、type background"]
    C --> D{{"并行构建 Go SSA<br/>最多 effective -p 个 worker"}}
    D --> E["串行修复 SSA 指令顺序"]
    E --> F["为所有 SSA 包预计算 caller tracking"]
    F --> G["串行包 preflight<br/>fingerprint/cache、SFiles、Plan 9 策略、<br/>后端分类；完成后冻结输入"]

    G --> H{"后端分类"}
    H -->|"patched package"| I["Coordinator 后端 + 立即发布 archive"]
    H -->|"Plan 9 asm、非 exe、<br/>ModeGen 或 ModuleHook"| J["Coordinator 后端 + 立即发布 archive"]
    H -->|"普通可执行包"| K{{"隔离的后端 worker<br/>最多 effective -p 个"}}

    K --> L["独立 llssa.Program<br/>独立 LLVM Context 和 TargetMachine"]
    L --> M["独立 lowering/type cache、<br/>ABI 状态和 C ABI transformer"]
    M --> N["LLVM lowering、passes 和 codegen"]
    N --> O["在同一个包任务中立即写 archive/cache"]
    O --> P["保留成功的 Program + LPkg<br/>直到 whole-program 消费者完成"]

    I --> Q["汇总包构建结果"]
    J --> Q
    P --> Q
    Q --> R["串行链接、method DCE、<br/>strong ABI override 和最终处理"]
    R --> S["清空 LPkg，并显式 Dispose<br/>所有保留的 worker Program"]

Loading

普通包会先构建，其 NeedRuntime 和 NeedPyInit 结果用于决定是否启用 runtime 包组，从而保持原来延迟启用 runtime 的行为。对于每个已经启用的后端包组，包之间相互独立，不存在 LLVM import 依赖 DAG。

archive 和 cache 发布属于包后端任务的一部分。每个包完成 codegen 后可以立即开始 I/O，不再集中到单独的发布阶段。

状态所有权

状态	所有权和生命周期
LLVM 工具发现和 PATH	属于进程背景，在进入 build.Do 前设置一次；包 worker 不修改它。
调用级 Config、cwd、环境变量	每次调用克隆或捕获一次，之后显式传递。
前端选项	属于当前 invocation 的 cl.Options；不依赖进程全局前端 debug 开关或全局锁。
Go packages、AST/type identity、Go SSA Program	由 coordinator 持有。Go SSA 包并行构建，完成后作为后端只读输入。
包语法元数据	linkname、export、closure-env directive、nointerface、type background、已解析语法身份和 locality 信息在后端启动前全部准备完成，之后直接只读共享。
Caller tracking	在启动后端 worker 前，为所有 Go SSA 包预计算一次；worker 只查询结果。
Fingerprint、缓存判断、SFiles 和 Plan 9 策略	在 coordinator 的包 preflight 阶段解析。worker 启动前冻结 SFiles。
后端 llssa.Program	每个隔离包独占一个，包含独立 LLVM Context、TargetMachine/TargetData、lowering cache、类型映射、ABI 映射和 Module。
C ABI transformer	每个后端 Program 独占，不在 worker 之间共享。
Archive/cache 发布	codegen 成功后立即在同一个包任务中执行。LLVM object 直接从 MemoryBuffer 写入 archive；同时可加入 cgo/Plan 9 产生的文件成员，不需要先把 LLVM object 落成临时 .o。
成功的 LPkg 和 worker Program	所有权转移给 coordinator，保留到链接期 DCE 和 ABI 消费者完成，然后在正常、错误和 panic 路径统一显式释放。

当前设计明确不包含全局 worker 锁、环境 snapshot/restore 包装、syntax delta 合并、syntax 校验阶段，也不要求先实现 PackageSummary。

并行度和调度方式

• -p=N 设置包 worker 的最大数量。
• 未显式设置 -p 时，默认使用 GOMAXPROCS。
• Go SSA 构建受这一数值限制。
• 隔离的 LLVM 后端任务也受这一数值限制。
• 两个 worker 阶段之间目前还存在 SSA 顺序修复、caller tracking 预计算和包 preflight；本方案暂不把 SSA 直接 pipeline 到 LLVM。
• preflight 完成后，LLVM 包作为一个扁平任务集合提交。此时 import 依赖已经不再约束 LLVM 调度；继续遵循依赖顺序只会降低并行度。
• worker 错误可以并发产生，但会按照确定的包输入顺序返回。
• patched 包和必须使用 coordinator 的包当前保持串行，并且不与 isolated worker 重叠。

兼容边界

以下情况继续走 coordinator 路径：

• 必须使用 coordinator Program 的 patched/alternate lowering；
• 使用选定 Plan 9 汇编的包；
• 非 executable build mode；
• ModeGen；
• 带 ModuleHook 的构建。

缓存命中仍保持原有链接语义：LLGo 会重建 whole-program 消费者需要的前端 Module，跳过后端 object emission，并把得到的包状态保留到链接完成。因此，当前还不能在 archive 发布后立即销毁所有 worker Program。

PR #1736 引入的链接期 method dead-code analysis 仍会读取活跃的包 Module。在这些信息被迁移到 Go 自有的 summary 之前，成功的 worker Program 必须保留到 linkMainPkg 完成。跨 Context 的 DCE 常量和 strong ABI 类型必须根据 Go 类型身份在目标 LLVM Context 中重新创建，不能直接把 LLVM Value 从一个 Context 传到另一个 Context。

构建调度 Trace

PR #2243 增加以下参数：

llgo build -debug-trace=/path/to/trace.json ...

输出采用 Chrome Trace Event JSON，可直接在 chrome://tracing 或 Perfetto 中打开。内容包括：

• 包加载和共享状态准备；
• 并行 Go SSA task；
• 串行 SSA 顺序修复、caller tracking 预计算和包 preflight；
• patched、coordinator 和 isolated 后端分类；
• 后端编译及紧随其后的 archive/cache 发布；
• SSA 到对应后端任务的直接 flow edge；
• 最终串行链接。

worker lane 与实际构建使用同一个 effective -p 上限。trace 文件通过 exclusive create 创建，不会静默覆盖已有源码、构建文件或旧 trace。trace flush 失败只会报告 warning，不会把本来成功的编译改成失败。

etcd 实际 Trace

测试目标为 go.etcd.io/etcd/server/v3，etcd commit 为 3e3b4c181c69。测试禁用了 LLGo 包构建缓存，并强制重新编译所有包：

LLGO_BUILD_CACHE=off llgo build -a -p=8 \
  -debug-trace=/tmp/etcd-p8.json \
  -o /tmp/etcd ./server

Trace 观察项	结果
带 trace 的墙钟时间	52.36 s
Go SSA task 数量	592
Go SSA 峰值并行度 / 阶段窗口	8 / 0.40 s
Caller tracking 预计算	14.14 s 串行
包 preflight	1.56 s 串行
Patched backend	11 个 task / 2.58 s 串行
其他 coordinator backend	11 个 task / 0.89 s 串行
Isolated LLVM backend	553 个 task
Isolated backend 峰值 / 平均并行度	8 / 7.19
8 个 isolated worker 全部活跃的时间	isolated 区间的 82.3%
Isolated backend 总工作量 / 实际窗口	156.41 task-s / 21.75 s
完整 backend 阶段	25.22 s
最终链接	8.37 s 串行

trace 表明真正耗时的 LLVM 区域已经实现包级并行，并且大部分时间能够占满请求的并行度。同时，它也暴露了接下来最大的串行优化目标：caller tracking 和最终链接。

不启用 trace 时，三次强制 etcd 构建的平均时间为：p=1 134.40 s，p=8 53.26 s，墙钟加速 2.52 倍。CPU 总量增加约 27.9%，峰值 RSS 从约 7.19 GB 增加到 7.40 GB。Kubernetes kubeadm 在相同的不复用包编译产物的测试方法下，从 439.31 s 降到 254.85 s，加速 1.72 倍。

使用相同输出路径重复执行 p=1 和 p=8 时，得到的二进制完全一致。写入不同输出路径时，差异只来自 Mach-O UUID 和包含输出文件名的 ad-hoc code signature 元数据，可执行代码和数据一致。

PR 列表

已合入的前置工作

• build: isolate invocation configuration and execution #2212：隔离 invocation 配置和执行；克隆 Config；捕获一次 cwd/environment；LLVM 工具发现保持为进程级背景；构建期间不再修改进程状态。
• compiler: always use main symbol prefix #2246：main symbol prefix 永远启用，移除可变的 RewriteMainPrefix 策略。
• compiler: isolate per-invocation frontend state #2221：前端选项改为 invocation-local，移除进程级前端 debug 开关和相关锁。
• build: Go Linktime-like Unreachable Method Pruning #1736：加入链接期 method DCE；这构成了当前必须保留 worker Module 到链接阶段的约束。
• build: split package compilation stages #2175：把包编译拆成 preflight、backend 和 publication；显式处理依赖和 fingerprint；LLVM 输出直接从内存写 archive；publication 属于对应包任务。

当前待合入实现栈

1. ssa: make recursive type conversion order-independent #2280：让互相递归类型的 Go-to-LLVM 转换不再依赖遍历顺序，避免独立 backend Program 产生不同 recursion placeholder。
2. build: prepare read-only package backend state #2282：一次准备包元数据并只读共享；为 backend 创建独立 Program，不引入 snapshot/overlay/delta 机制。
3. build: run LLVM package backends in parallel #2182：进行包分类，运行有界 isolated LLVM worker，立即发布 archive，保留成功 Program 到链接阶段，并保证确定释放。
4. build: add Chrome scheduler trace #2243：在 build: run LLVM package backends in parallel #2182 之上增加 Chrome/Perfetto 构建调度 trace。

已经关闭的 SSA-to-backend pipeline、独立 parallel-publish 等实验 PR 不属于当前方案。publication 已经是 backend task 的一部分；而 etcd trace 显示 Go SSA 自身只有约 0.40 s，相比之下 caller tracking 为 14.14 s、backend 为 25.22 s，因此当前继续投入 SSA/backend pipeline 并不是收益最高的优化方向。

考虑过的其他方案

直接把旧包构建循环放进 goroutine

不采用。旧循环共享 LLVM Context、TargetMachine、lowering cache、ABI 状态、包元数据修改、环境/cwd 行为和链接期 Module。

按 import 依赖调度 LLVM 包

不采用。import 顺序只在构建和准备 Go SSA/前端状态时有意义。进入 LLVM 后，各包可以独立 lowering；继续强制 import DAG 会降低并行度，但不会增加正确性。

用全局锁保护共享后端状态

不采用。这只会形成表面并行，并继续让不同构建调用依赖进程全局状态。

只并行 LLVM pass/codegen，共享前端 Program

当前不采用。创建和 lowering 包 Module 的过程本身已经会访问 LLVM Context 持有的 type/value 状态。安全隔离边界是一个完整 backend Program，而不是很晚的 pass-manager 阶段。

启用 worker 前必须先实现 PackageSummary

暂缓。完整 summary 对降低保留内存很有价值，但必须覆盖 DCE、ABI override、method table、global、funcinfo/PCLN、C export、runtime flag 和 cache metadata 等所有链接期消费者。当前保留 Program 能够先保持原有语义并尽快启用并行能力。

把 SSA 直接 pipeline 到 LLVM

暂缓。该方案需要增量 caller/dependency 准备，或者增加另一层同步边界。当前 trace 显示 SSA 本身在 etcd 构建中占比很小，优先优化 caller tracking 和链接更有价值。

风险和处理方式

• 峰值内存： 多个 LLVM Module 会同时保留到链接完成。通过 -p 控制上限，后续通过 PackageSummary 提前释放。
• 跨 Context LLVM Value： 根据 Go 侧类型身份重新创建类型和常量，并验证每个 worker Module；禁止直接跨 Program 传递原始 LLVM Value。
• 不确定性： 保持包和结果顺序确定，比较 p=1 与 p=8，并检查输出代码和数据。
• 失败释放： worker 仅在成功后转移所有权；coordinator 的 defer 会在正常、错误和 panic 路径先清除所有 LPkg 引用，再 Dispose Program。
• fallback 行为： 不支持隔离的模式和包继续走原有 coordinator 路径，不实现不完整的隔离行为。
• 可观测性： scheduler trace 属于单次 build，默认关闭；关闭时不存在共享 trace 状态或输出文件。

验证和验收标准

• 按依赖顺序合入：ssa: make recursive type conversion order-independent #2280、build: prepare read-only package backend state #2282、build: run LLVM package backends in parallel #2182、build: add Chrome scheduler trace #2243。
• 通过 ssa、cl、internal/build、internal/dcepass、命令和环境相关测试。
• 通过 concurrent invocation、backend Program 共享、caller tracking、worker scheduling、DCE Context clone、Program 保留和释放相关 race 测试。
• 通过完整 symbol/testdrop 测试和 LLVM verifier。
• 覆盖 p=1/p=8 的冷、热包缓存构建。
• 覆盖普通 Go、cgo、Plan 9 汇编、patched runtime 包、LTO 和 cache-hit linking。
• 验证串行和并行构建输出代码/数据的确定性。
• 对大型软件记录 wall、user+sys CPU 和 peak RSS。
• 在链接及 whole-program transform 形成独立并通过检视的所有权模型之前，继续保持它们串行。

后续工作

1. 降低或并行 caller tracking 预计算；当前在 etcd trace 中耗时 14.14 s。
2. 定义 PackageSummary，把链接/DCE 消费者迁移到 Go 自有数据，使 worker LLVM Module 可以更早释放。
3. 研究在不破坏状态所有权的前提下，让 coordinator-only 包与 isolated worker 重叠执行。
4. 只有在真实 workload 中测得明显收益后，再重新评估 Plan 9 汇编并行化。
5. 在 benchmark/CI 分析中使用 scheduler trace，持续观察 lane 利用率、长尾包和性能回退。