llvm代码生成阶段通过分层降级机制处理不支持指令：先尝试原生指令实现，再expand为等效指令序列，最后fallback至compiler-rt/libgcc库函数调用，全程“软适配”而非硬失败。
LLVM在代码生成阶段遇到目标CPU不支持的指令或操作时，不会直接报错退出，而是通过一套分层降级机制来处理：先尝试用目标后端原生支持的指令实现，不行就拆成多条等效指令，再不行就调用运行时库函数（compiler-rt 或 libgcc）。这个过程不是“硬失败”，而是“软适配”。
后端指令选择失败时会 fallback 到 Legalization
LLVM后端（如 ARMTargetLowering、X86TargetLowering）在指令选择（Instruction Selection）前会先做 LegalizeTypes 和 LegalizeOps。如果某个 IR 操作（比如 llvm.uadd.with.overflow.i128）在目标架构上没有对应机器指令：
- 类型不合法（如 i128 在 32 位 ARM 上）→ 拆成两个 i64 操作 + 进位链
- 操作不合法（如原子 cmpxchg on unaligned address）→ 插入自旋锁 + load/store 序列
- Legalizer 会标记该节点为
Expand或Libcall，交由后续阶段处理
Expand 模式：用基础指令序列模拟高级操作
当 LegalizeOps 决定 Expand 时，LLVM 会在 SelectionDAG 构建阶段把一个 IR 节点替换成多个等价的 SDNode。例如：
llvm.sadd.with.overflow.i64 → { add + adc }（x86）
llvm.ctpop.i256 → 四次 <code>popcnt</code> + add（若支持 popcnt）或逐字节查表（若不支持）
这种展开是纯静态的，不依赖运行时，但会增加指令数和寄存器压力。你可以在 llvm/lib/Target/*/TargetLowering.cpp 里看到大量 LowerOperation 函数实现这类逻辑。
Libcall 模式：调用 compiler-rt 中的软件实现
对实在无法用指令序列高效实现的操作（如 __int128 除法、sqrtf128），LLVM 会生成对 compiler-rt 中函数的调用：
-
__udivti3（无符号 128 位除法） -
__floatundisf（uint64_t → float） -
__mulxc3（复数乘法）
这些函数默认随 clang 链接进可执行文件；若显式禁用（-nodefaultlibs），链接会失败，错误信息类似：undefined reference to '__udivti3'。此时需手动链接 compiler-rt 的静态库。
运行时 dispatch 不是 LLVM 的默认行为
注意：LLVM 本身不做 CPU 特性运行时检测（比如 AVX 是否可用），那是 libc++ 或用户代码的事。LLVM 的目标三元组（如 -march=haswell）只影响编译期生成的指令集——它假设你承诺目标机器一定支持。如果你需要真正的运行时分支（如 AVX / SSE4.2 自适应），得靠 __builtin_cpu_supports("avx") 手动写条件逻辑，LLVM 只负责把那个 builtin 编译成对应的 cpuid 检查指令。
