从这个问题开始：how-do-i-check-if-gcc-is-performing-tail-recursion-optimization，我注意到使用带有-fPIC的gcc似乎会破坏这种优化 . 我正在创建一个共享库，但我似乎不需要-fPIC选项 .
好吧，我的问题是，为什么-fPIC会改变gcc优化？我是否需要以任何理由保留-fPIC？
从这个问题开始：how-do-i-check-if-gcc-is-performing-tail-recursion-optimization，我注意到使用带有-fPIC的gcc似乎会破坏这种优化 . 我正在创建一个共享库，但我似乎不需要-fPIC选项 .
好吧，我的问题是，为什么-fPIC会改变gcc优化？我是否需要以任何理由保留-fPIC？
2 回答
在缺少目标体系结构和编译器版本等细节的情况下，可能的解释如下：
在位置相关的代码中，尾递归优化本质上是重用当前的堆栈帧，并用
jump替换所考虑的call. 语法可能被call function替换为jmp <small offset of function>.在与位置无关的代码中，如果指令集允许，则可以写入
call function@PLT（此示例为amd64） . 它完全可以被jmp <small offset of function>@PLT取代，但这两个设置确实会产生干扰，并且gcc开发人员可能无法在后一种模式下实现尾调用优化 .在ia32 linux中，使用fpic意味着您没有可用于通用目的的ebx，这肯定会影响优化 . 由于寄存器调度压力，编译器可能决定不进行尾递归优化 .