gcc -fPIC 似乎与优化标志混在一起
从这个问题开始： how-do- i-check-if-gcc-is-performing-tail-recursion-optimization，我注意到将 gcc 与 -fPIC 一起使用似乎会破坏这种优化。我正在创建一个共享库，但我似乎不需要 -fPIC 选项。
好吧，我的问题是，为什么 -fPIC 会改变 gcc 优化？我是否需要出于任何原因保留 -fPIC ？
Following along from this question: how-do-i-check-if-gcc-is-performing-tail-recursion-optimization, I noticed that using gcc with -fPIC seems to destroy this optimization. I am creating a shared library, but I doesn't seem to need the -fPIC option.
Well, my question is, why does -fPIC change gcc optimizations ? Do I need to keep -fPIC for any reason ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在缺乏目标架构和编译器版本等细节的情况下，可能的解释是：
在位置相关代码中，尾递归优化本质上是重用当前堆栈帧，并替换所考虑的
调用通过跳跃。语法可以是call function替换为jmp <函数的小偏移量>。在与位置无关的代码中，如果指令集允许（本示例为 amd64），则可以将调用编写为
call function@PLT。它完全可以被jmp <函数的小偏移量>@PLT取代，但这两个设置确实会相互干扰，也许 gcc 开发人员没有抽出时间在后一种模式下实现尾部调用优化。In absence of details such as target architecture and compiler version, a possible explanation is this:
In position-dependent code, the tail-recursion optimization is essentially to reuse the current stack frame, and to replace the considered
callby ajump. The syntax may becall functionreplaced byjmp <small offset of function>.In position-independent code, the call may be written
call function@PLTif the instruction set allows it (this example is amd64). It could perfectly well be replaced byjmp <small offset of function>@PLT, but the two settings do interfere and perhaps gcc developers did not get around to implementing tail-call optimization in the latter mode.在ia32 linux中，使用fpic意味着您没有可用于通用用途的ebx，这肯定会影响优化。也许由于寄存器调度压力，编译器决定不进行尾递归优化。
In ia32 linux, use of fpic means that you don't have ebx available for general purpose use, which will surely impact optimization. Perhaps the compiler decided against the tail recursion optimization due to register scheduling pressure.