Turbofan IR操作符的Speculative与Checked前缀含义是什么

这两类操作符都和TurboFan的类型假设校验、去优化（Deoptimization）机制相关，核心区别在于检查的强制程度和设计目的：

Checked* 前缀操作符 #

• 代表强制语义检查：这类操作的校验逻辑是JS语义硬性要求的，不会随优化流程、类型反馈变化被移除，只要运行时检测到操作数/结果不符合约束，就立刻触发去优化回退到解释器。
• 常见行为：比如CheckedInt32Add会校验两个输入是否为合法Int32值、加法结果是否溢出Int32范围；CheckedFloat64ToInt32会校验输入的浮点数是否可无损转换为Int32（不能是NaN、±Infinity，也不能超出Int32取值边界），校验不通过直接走去优化逻辑。
• 适用场景：多用于JS语义本身要求必须做合法性校验的位置，比如数组下标访问前的索引范围校验、位运算结果的整数转换等，不存在投机成分，检查是必须执行的。

Speculative* 前缀操作符 #

• 代表投机性优化的兜底检查：这类操作完全基于Ignition解释器前期收集的类型反馈生成，编译器“赌”实际运行时输入符合反馈的类型，直接生成对应快速路径的代码，再加一层兜底检查防错。
• 常见行为：比如SpeculativeSafeIntegerAdd是编译器根据反馈推测两个操作数都是安全整数、加法结果也不会溢出安全整数范围，直接走高效的整数加法逻辑，一旦实际运行时发现操作数类型不对、结果溢出，就触发去优化，回退到通用JS加法逻辑执行，同时更新类型反馈，下次重新编译时不会再做这个错误的投机假设。
• 适用场景：所有基于概率性类型反馈做的投机优化位置，如果后续优化阶段通过类型流分析能证明这个投机假设恒成立（比如能确定两个操作数必然是小整数Smi），这层兜底检查会被直接删掉，替换成无任何额外开销的原生算术操作。

核心差异总结：Checked*的检查是语义要求的硬约束，永远不会被优化消除；Speculative*的检查是投机优化的软兜底，只要能证明假设成立就可以被移除。

内容的提问来源于stack exchange，提问作者Seungwan Kwon