optnone仅禁用中端优化pass（如instcombine、gvn、loopvectorize），不阻止前端变换和后端指令选择，故无法保障常量时间；需结合专用属性、定制pass及后端约束才能实现真正侧信道安全。
optnone属性会直接禁用中端优化Pass
LLVM 的 optnone 属性不是“建议”，而是明确的指令：跳过该函数的所有中端优化（Mid-level IR optimizations）。它通常出现在 -O0 编译输出中，目的是保留原始源码结构、便于调试。一旦函数被标记为 optnone，像 InstCombine、GVN、LoopRotate 这类基于 IR 的 FunctionPass 就会在入口处主动返回 false，不执行任何变换。
哪些Pass会被跳过，哪些仍会运行
被跳过的主要是中端优化 Pass：
-
InstCombine：不会尝试把(x | (0 - x)) >> 31合并成select -
GVN：不会消除看似重复、实则依赖秘密值的计算 -
LoopVectorize：不会向量化循环，避免访存模式暴露密钥长度
但以下 Pass 通常仍会运行：
-
Verifier：IR 合法性检查不受影响 -
StripDeadPrototypes：清理未定义函数声明 - 自定义 Pass（除非显式检查
F.hasFnAttribute(Attribute::OptimizeNone)）
为什么不能靠 optnone 保常量时间
这是最容易踩的坑：optnone 只挡中端，不挡后端。即使函数没被 InstCombine 动过，X86 后端仍可能在 SelectionDAG 阶段把 select lower 成 cmov，而 cmov 在某些微架构上延迟与操作数相关；AArch64 后端也可能把 select 映射为 csel，虽比分支安全，但仍非严格常量时间（取决于条件标志生成路径）。更关键的是，optnone 不阻止前端（如 Clang）在生成 IR 前就做掉一些“语义等价但时序泄露”的变换。
真正需要的是显式 CT 属性与 Pass 约束
仅靠 optnone 守不住常量时间边界。生产级密码代码需要：
- 在 IR 层引入新属性，如
constanttime或sideeffectfree，并让后端识别 - 定制 Pass 主动拒绝修改带该属性的指令（比如禁止把
icmp+select合并） - 后端在 Instruction Selection 阶段对敏感指令做约束映射（例如强制
select→csel而非cmov） - 验证工具链（如 ct-verif）在 IR 和汇编两个层级检查访存/分支/ALU 指令是否与秘密值无关
换句话说，optnone 是个调试开关，不是安全契约。想让 LLVM 真正理解“这个函数不能以任何方式泄露秘密”，得从属性设计、Pass 行为、后端规则到验证闭环全部重写。
