この質問に続いて: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を保持する必要がありますか?
ターゲットアーキテクチャやコンパイラバージョンなどの詳細がない場合、考えられる説明は次のとおりです。
位置に依存するコードでは、末尾再帰の最適化は、基本的に現在のスタックフレームを再利用し、考慮call
されたものを。に置き換えることjump
です。構文は。にcall function
置き換えることができますjmp <small offset of function>
。
位置に依存しないコードではcall function@PLT
、命令セットで許可されている場合は呼び出しを記述できます(この例はamd64です)。これは完全にに置き換えることができjmp <small offset of function>@PLT
ますが、2つの設定は干渉し、おそらくgcc開発者は後者のモードで末尾呼び出しの最適化を実装することに慣れていませんでした。
ia32 Linux では、fpic を使用すると、ebx を汎用目的で使用できないことになり、最適化に確実に影響します。おそらく、コンパイラーは、レジスター・スケジューリングの圧力により、末尾再帰の最適化に反対する決定を下しました。