LLVM IR中frame-pointer属性与性能关系及性能劣化问题咨询

frame-pointer=none确实会省略RBP寄存器的栈帧初始化操作（进入函数时的push rbp; mov rbp, rsp、退出时的pop rbp），同时释放RBP作为通用寄存器给编译器调度使用，理论上应该带来性能收益。出现性能反降是该优化触发了其他隐性的负面效应，从你的perf数据可以直接定位根因。

你给出的perf数据有两个核心特征：

• 两个版本执行的总指令数几乎完全一致（600亿左右），说明没有生成冗余代码
• 每周期指令数(IPC)从4.59暴跌到2.0，同时cache访问量上升10%、cache miss量上升147%
  这说明程序执行的瓶颈不在指令数量，而在流水线执行效率和访存延迟，你的场景下最可能的原因如下：

1. 栈寻址引入的地址生成依赖卡住了流水线 #

当关闭帧指针后，所有栈上变量的寻址都需要基于RSP寄存器计算：

• 插入排序的内层循环是访存密集型逻辑，当编译器用RSP作为基址寻址时，地址生成操作和栈操作（如果有动态栈调整）会形成串行依赖，无法并行发射
• 而使用RBP作为基址时，RBP的值在函数执行全程固定，地址生成可以提前完成，没有依赖阻碍流水线发射，所以IPC更高

2. 额外通用寄存器的调度反而破坏了缓存局部性 #

虽然多了一个RBP可用，但编译器在寄存器分配时可能做出了更差的决策：比如把原本可以连续排布的热点指令拆分，或是把高频访问的临时变量溢出到栈上，导致指令/数据缓存的命中率下降，你观察到的cache引用量、cache miss量同步上升就是直接表现。

3. 自定义优化序列和无帧指针模式的兼容性问题 #

你使用了自定义的LLVM优化序列，无帧指针模式下会改变寄存器分配、指令调度的决策逻辑，如果你的优化序列没有针对该模式做适配，很可能出现调度逻辑混乱，把内层循环的关键路径指令排到了同一条流水线执行，直接拉低IPC。
插入排序的时间复杂度为O(n²)，20万元素的测试用例会让内层循环执行数十亿次，微小的调度差异会被放大到一倍以上的性能差距，完全符合你观察到的测试结果。

你可以通过以下方式确认根因：

• 用objdump -d分别反汇编两个版本的insertionSort函数，对比内层循环的指令编码、寻址方式、寄存器分配差异
• 用perf增加dTLB-load-misses、uops_dispatched_port.port_*等硬件事件采样，确认是地址生成瓶颈还是流水线端口冲突

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