LLVM后端不直接编码机器指令，而是通过指令选择、寄存器分配、代码发射三阶段协同完成：先将IR映射为SelectionDAG节点并匹配TableGen定义的指令模式，再分配物理寄存器，最后生成带真实编码的MCInst。
LLVM后端不直接“编码机器指令”，而是靠指令选择 + 寄存器分配 + 代码发射三阶段协同完成
你没法像手写汇编那样用 mov r0, #42 直接塞进 LLVM 后端。LLVM 后端的职责是把优化后的 LLVM IR 转成目标平台可执行的机器码，这个过程完全自动化、分阶段、且高度依赖 TableGen 描述和 C++ 实现的 target-specific 逻辑。
真正“编码机器指令”的动作发生在最后的 Code Emission 阶段，但前提是前面两步已把语义明确地映射到具体硬件资源上：指令选择决定“用哪条指令”，寄存器分配决定“用哪些物理寄存器”，之后才能生成带真实编码的 MCInst。
-
SelectionDAG是关键中间态：IR 中的%1 = add i32 %a, %b会被 lowering 成ISD::ADD节点，再通过 pattern matching 匹配到 RISC-V 的add或 ARM 的add w0, w1, w2 - TableGen 文件（如
RISCVInstrInfo.td）定义了所有合法指令格式、操作数约束、编码位域——没在这里声明的指令，后端根本“不认识” - 寄存器分配失败时，
add可能被拆成mov x0, %a; mov x1, %b; add x2, x0, x1，甚至插入栈溢出/重载指令，这不是你写的，是RegisterCoalescer或LiveIntervals决定的
想让某条自定义指令出现在最终二进制里，必须走通 builtin → intrinsic → ISD node → SelectionDAG pattern → MCInst 全链路
比如你想在 RISC-V 上支持一条新指令 clz（count leading zeros），不能只改汇编器或链接器；LLVM 后端要能“看见它、理解它、选中它、发出它”。这需要至少四个位置同步修改：
- Clang 前端加
__builtin_riscv_clz声明，并在CGBuiltins.cpp中把它降级为@llvm.riscv.clzintrinsic 调用 - LLVM IR 层要有对应 intrinsic 声明（
llvm/lib/IR/IntrinsicsRISCV.td），否则 IR verifier 会报错 - Target lowering 阶段（
lib/Target/RISCV/RISCVISelLowering.cpp）要把 intrinsic 转成自定义的RISCVISD::CLZ节点，而不是丢给通用 fallback - SelectionDAG pattern（
lib/Target/RISCV/RISCVInstrInfo.td）中必须有匹配RISCVISD::CLZ的 rule，且指定其编码字段（如def CLZ : RVInst<...> { ... let Inst{31-25} = 0b0110000; }</...>）
漏掉任意一环，结果都是：你的 C 代码调用了 __builtin_riscv_clz，但最终生成的汇编里还是 call __clzsi2（软实现）或者直接报错 error: cannot select: t10: i32 = intrinsic<llvm.riscv.clz>。
调试机器指令生成，重点看 llc -debug-pass=Structure 和 -print-machineinstrs 输出
光看 .ll 文件或最终 .s 汇编，无法定位“为什么没选我的指令”。真正有效的调试入口是 llc 的中间表示输出：
-
llc -march=riscv32 input.ll -debug-pass=Structure 2>&1 | grep -A5 -B5 "CLZ"能确认RISCVISD::CLZ节点是否成功构建 -
llc -march=riscv32 -print-machineinstrs input.ll显示的是MachineInstr层指令，形如CLZW %w0, %w1 :: (set %w0, (riscv_clzw %w1))，这时已绑定寄存器，但还没编码 -
llc -march=riscv32 -show-mc-inst input.ll才显示最终MCInst编码，例如CLZW <mcinst reg:1024><mcoperand reg:1025>></mcoperand></mcinst>，再往后就是二进制字节流了
如果 -print-machineinstrs 里看不到你的指令名，说明 instruction selection 失败；如果看到了但 -show-mc-inst 里没出现对应 MCInst，问题大概率出在 getMachineOpValue 或 encodeInstruction 的 C++ 实现里——这些函数负责把 MachineInstr 的操作数填进 opcode 模板的 bit 位中。
硬编码机器指令（比如 patch 一个立即数）几乎总是错的，要用 MC layer 的接口
有人想“绕过流程”，直接在 EmitInstruction 里写死 OS.emitInt32(0x01f0000f); 来发一条 RISC-V addi。这看似快，实则埋雷：
- 立即数范围校验丢失：若你填的
#4097超出 12-bit，硬件执行会出错，而正常流程会在SelectionDAG阶段就触发CannotSelect - 寄存器重命名失效：硬编码的
rd和rs1字段不会随寄存器分配结果动态更新，导致指令读错寄存器 - 无法参与指令调度：硬编码指令脱离了
MachineBasicBlock的 DAG 结构，ScheduleDAGMILive完全无法优化其位置 - 调试信息断链：
DebugLoc和MachineInstr::getDebugLoc()不会关联到你手写的字节，gdb 单步会跳过
正确做法是确保你的指令在 RISCVInstrInfo.td 中正确定义了 let isPseudo = 0（非伪指令），并实现好 RISCVMCCodeEmitter::encodeInstruction ——这里才是唯一该做位操作的地方，而且它接收的是已验证、已分配、已调度完毕的 MachineInstr 对象。
