lld 默认不启用 thinlto 并行；thinlto 并行由 clang 通过 -mllvm -threads=n 控制，需显式指定且仅对 -flto=thin 生效，lld 本身无并行开关。
lld 默认是否启用 ThinLTO 并行？
不启用 —— lld 本身不主动触发 LTO，它只是链接器；ThinLTO 的并行行为由 Clang 驱动和 LLVM 优化器控制，lld 只负责加载 bitcode、调用 llvm-lto 或内置 LTO pipeline。真正决定并行度的是 Clang 编译/链接命令中传给 LLVM 后端的线程数参数，lld 自身没有 --threads 或类似开关。
-flto=thin 编译时如何指定并行线程数？
用 -mllvm -threads=N（注意是 -mllvm，不是 -llvm），该参数必须在编译或链接命令中显式传递给 Clang，且仅对 ThinLTO 生效：
-
-mllvm -threads=4：限制 ThinLTO 后端优化阶段最多使用 4 个线程 - 该参数需放在
-flto=thin同一命令中，否则被忽略（例如只在编译阶段加，链接阶段没加，则链接时仍用默认线程数） - Clang 17+ 默认线程数为
min(available_cores, 8)，不是无限制；但高核数机器上可能触发调度抖动，手动设为4或6常更稳
为什么 -jobs=N 不影响 ThinLTO 并行度？
-jobs=N 是 CMake 或 ninja 的构建系统级并发控制，只管“同时跑几个 clang 进程”，跟单个 clang 进程内部的 ThinLTO 多线程无关。两者正交：
-
ninja -j8：启动 8 个独立的clang -c ... -flto=thin进程（编译阶段并行） -
-mllvm -threads=4：每个clang在链接阶段调用 LLVM LTO pipeline 时，内部最多开 4 个线程做函数导入、内联、codegen - 若不设
-mllvm -threads，单个链接命令可能占满所有 CPU，导致构建系统其他任务饥饿
实测建议与易错点
在 CI 或内存受限环境里，ThinLTO 并行度失控是常见 OOM 根源。关键要区分两层并发：
- 编译阶段（多文件 .c → .o）：靠构建系统控制（
ninja -j4） - LTO 阶段（.o → 可执行文件）：必须靠
-mllvm -threads=N约束，N 建议 ≤ 总物理核心数的一半 - 漏掉
-mllvm前缀会静默失效 ——-threads=4被当作文本参数丢弃，不会报错 - Clang 17 开始支持
-flto=thin -mllvm -lto-legacy-pass-manager=0切新 Pass Manager，此时-mllvm -threads依然有效，但旧 PM 下行为略有差异（如 alias analysis 并行粒度不同）
真正需要调的只有 -mllvm -threads 这一个参数，其余所谓 “lld 控制” 都是误解。它不起眼，但不加就容易在 64 核机器上把构建机拖垮。
