SelectionDAG是当前主流、稳定、可调试的指令选择框架；GlobalISel是正在演进的替代方案，目标是统一IR表示、支持增量lowering和更易维护，但多数后端仍不完全可用。
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）。这意味着：
- 不再依赖
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）中，
defmfor SelectionDAG 和definstfor GlobalISel 是两套语法，混写会导致llvm-tblgen报Unknown node type
真正难的不是选哪个框架，而是在 GlobalISel 尚未 fully replace SelectionDAG 的当下，如何让自己的 lowering 逻辑既能被旧流程 consume，又为新流程留出扩展点——比如把寄存器分配约束抽象成 TargetRegisterInfo 子类，而不是硬编码在 Select 函数里。
