LLVM IR能同时用于JIT和离线编译，根本原因在于其语言无关、目标无关、执行时机无关的特性；只要满足类型安全、SSA形式、显式linkage、无硬编码地址、符号定义完整等条件，同一份IR即可被llc或ORC JIT消费。
LLVM 能让同一份 IR 同时用于 JIT 和离线编译，根本原因在于 IR 本身是**语言无关、目标无关、执行时机无关**的中间表示。只要 IR 合法（符合 LLVM 的类型系统、SSA 形式、控制流结构等约束），它就能被不同后端消费——不关心你之后是用 llc 生成 .o 文件，还是用 ORC JIT 在内存里即时发射机器码。
IR 必须满足哪些基本条件才能双用途
不是所有生成的 IR 都能无缝用于 JIT 和 AOT。关键在于避免引入“绑定到特定执行环境”的隐含假设：
-
不能依赖未定义符号的链接时解析：比如在 IR 中直接调用
@printf但没声明其签名或未链接 libc，JIT 可能因找不到符号而失败，而clang -O2离线编译却能靠链接器兜底； -
避免硬编码绝对地址或段偏移：IR 中不应出现
inttoptr转换到固定地址（如inttoptr i64 0x7fff12345000 to i32*），这在 JIT 下会出错； -
全局变量需明确 linkage 类型：用
internal或external显式声明，避免private在某些 JIT 场景下引发符号查找歧义； -
函数调用约定要一致：若 IR 中用了
cc 11（X86_64_SysV）、cc 9（FastCall）等显式调用约定，JIT 引擎和 AOT 后端必须都支持该约定，否则 JIT 可能拒绝执行。
ORC JIT 和 llc 对 IR 的处理路径差异
同一份 Module* 实例，在 JIT 和 AOT 下走的是完全不同的后端管道，但输入接口一致：
-
llc（离线编译）：读取 IR 文本或 bitcode → 构建TargetMachine→ 调用addPassesToEmitFile插入 CodeGenPass → 输出汇编或对象文件； -
ORC JIT（运行时编译）：把Module交给ExecutionSession→ 经IRCompileLayer编译为 in-memory object →ObjectLinkingLayer解析重定位 → 最终由MemoryMapper分配可执行内存页并跳转执行； - 二者共享同一套
LLVMTargetMachine配置（如Triple、CPU、Features），所以生成的机器码语义一致； - 区别在于：JIT 需实时解决符号解析（比如对
@malloc的调用），而llc只负责生成带重定位信息的 .o，留给链接器收尾。
常见踩坑：为什么 IR 在 llc 里能过，JIT 却报错
典型错误往往出现在符号绑定和运行时依赖环节：
-
Symbol not found: @sin：IR 中调用了@sin，但 ORC JIT 没注册对应符号解析器（SymbolResolver），而llc不管这个，只输出 undefined symbol 到 .o； -
Cannot select: t12: i64 = GlobalAddress<i64> @my_helper</i64>：IR 中用了外部函数指针但没设externally_initialized属性，JIT 在代码生成阶段无法确定地址； -
Invalid relocations for section __TEXT,__text（macOS）：IR 中用了thread_local全局变量，但 JIT 运行时未启用 TLS 支持，而llc生成的 Mach-O 可以靠 dyld 处理； - 使用了
llvm.dbg.*元数据但没禁用调试信息：JIT 默认忽略 debug info，但某些旧版 ORC（如 JITLegacy）可能因元数据格式异常崩溃，而llc完全兼容。
真正难处理的不是 IR 生成，而是让 JIT 运行时环境“假装自己是链接器+加载器”。IR 本身很干净，但把它跑起来，得补全符号、内存布局、异常表、栈展开信息——这些在 AOT 里是工具链分阶段完成的，JIT 得一次性扛下来。
