LLVM SelectionDAG和GlobalISel在代码生成中有何区别-C++-PHP中文网

selectiondag是当前主流、稳定、可调试的指令选择框架；globalisel是正在演进的替代方案，目标是统一ir表示、支持增量lowering和更易维护，但多数后端仍不完全可用。

llvm selectiondag和globalisel在代码生成中有何区别

SelectionDAG 是当前主流、稳定、可调试的指令选择框架；GlobalISel 是正在演进的替代方案，目标是统一 IR 表示、支持增量 lowering 和更易维护，但目前在多数后端（尤其非 x86/AArch64）仍不完全可用。

SelectionDAG 仍是默认且最成熟的路径

几乎所有 LLVM 官方支持的目标（RISC-V、ARM、X86 等）都完整实现了 XXXISelDAGToDAG.cpp 和 XXXISelLowering.cpp，整个流程基于 SDNode/SDValue 构建有向无环图，再通过 pattern-matching（td 文件 + C++ Select 实现）转成 MachineInstr。它的优势在于：

调试友好：llc -view-dag-combine1-dags 可视化每阶段 DAG 变化，-debug-only=isel 输出详细匹配日志
Lowering 与 selection 分离清晰：先合法化（LegalizeTypes/LegalizeOps），再 combine，最后 select，各阶段职责明确
对复杂 calling convention、custom lowering（如 ISD::BRCOND 拆成 cmp+jmp）、target-specific memory ops 支持成熟

GlobalISel 的设计目标不是“更快”，而是“更可控”

它绕过 SelectionDAG，直接在 GISelKnownBits 和 MachineIRBuilder 上操作，用 GISelChangeObserver 驱动 lowering，核心数据结构是 GISelInst 和 LLT（而非 EVT）。这意味着：

Agent Browser

一款AI工具，主要用于一款基于 Rust 的快速无头浏览器自动化命令行工具（CLI），支持 Node.js 回退机制，可使 AI agent 通过结构化命令实现页面导航、点击、输入及截图，适合需要提升相关任务效率的用户。

下载

不再依赖 SelectionDAG 的链（chain）模型，memory ordering 更贴近 MLIR 风格，适合与 MLIR 后端协同
lowering 是按 instruction 增量进行的，便于插入自定义逻辑（比如在某个 G_ADD 后立即插 barrier）
但目前 GlobalISel 的 target support 仍不完整：RISC-V 的 RISCVInstructionSelector.cpp 在 2026 年仍未覆盖所有浮点异常模式；ARM 的 ARMLegalizerInfo 对某些 NEON 向量类型仍 fallback 到 SelectionDAG

编译时如何选择？关键看 `-fast-isel` 和 `-global-isel` 的实际行为

这两个 flag 不是互斥开关，而是控制不同层级的 fallback 路径：

llc -O2 -global-isel：优先走 GlobalISel；若某条指令未被 legalizer 或 selector 处理，则自动 fallback 到 SelectionDAG（不会报错，但会打 warning 日志）
llc -O0 -fast-isel：跳过 GlobalISel 和 SelectionDAG，直接用 table-driven fast-path（仅支持简单算术+load/store，无优化）
真正禁用 SelectionDAG 需要 patch TargetMachine::addPassesToEmitFile，移除 addISelPasses 中对 SelectionDAGISel 的注册——但这会导致大多数后端直接 crash

容易踩的坑：别在 custom backend 里混用两种 lowering 逻辑

如果你正在写 RISC-V 或 ARM 的 target-specific Pass，要注意：

在 SelectionDAGISel::Select 里调用 CurDAG->getMachineNode 是安全的；但在 GlobalISel 的 selectImpl 里调用同名函数会编译失败——它只认 Builder.buildInstr
ISD:: 节点（如 ISD::SRA）只存在于 SelectionDAG 流程；GlobalISel 使用 G_ASHR 等 G_* opcode，二者不能跨流程引用
TableGen 描述文件（.td）中，defm for SelectionDAG 和 definst for GlobalISel 是两套语法，混写会导致 llvm-tblgen 报 Unknown node type

真正难的不是选哪个框架，而是在 GlobalISel 尚未 fully replace SelectionDAG 的当下，如何让自己的 lowering 逻辑既能被旧流程 consume，又为新流程留出扩展点——比如把寄存器分配约束抽象成 TargetRegisterInfo 子类，而不是硬编码在 Select 函数里。