コードが末尾呼び出しの最適化を積極的に防止しようとするのはなぜですか？

質問のタイトルは少し奇妙かもしれませんが、私が知る限り、末尾呼び出しの最適化に反対するものは何もありません。しかし、オープンソースプロジェクトを閲覧しているときに、コンパイラが末尾呼び出しの最適化を実行するのを積極的に阻止しようとするいくつかの関数にすでに遭遇しました。たとえば、そのようなハックでいっぱいのCFRunLoopRefの実装です。例えば：

static void __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__() __attribute__((noinline));
static void __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(CFRunLoopObserverCallBack func, CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
    if (func) {
        func(observer, activity, info);
    }
    getpid(); // thwart tail-call optimization
}

なぜこれがそれほど重要に見えるのか知りたいのですが、通常の開発者として私もこれを念頭に置いておく必要がある場合はありますか？例えば。末尾呼び出しの最適化に関する一般的な落とし穴はありますか？

ここでの私の推測は、__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__デバッグの目的でそれがスタックトレースにあることを確認することです。それは__attribute__((no inline))この考えを裏付けるものを持っています。

お気づきの方もいらっしゃると思いますが、その関数はとにかく別の関数に行き来するので、デバッグを支援するためにそのような冗長な名前が付いているとしか思えないトランポリンの形式です。これは、関数が他の場所から登録された関数ポインターを呼び出しているため、その関数にアクセス可能なデバッグシンボルがない可能性がある場合に特に役立ちます。

同様のことを行う他の同様の名前の関数にも注意してください-バックトレースから何が起こったかを確認するのに役立つように見えます。これはコアMacOS Xコードであり、クラッシュレポートやプロセスサンプルレポートにも表示されることに注意してください。

これは単なる推測ですが、スタックオーバーフローエラーで爆破するのではなく、無限ループを回避するためかもしれません。

問題のメソッドはスタックに何も配置しないため、末尾呼び出しの再帰最適化では、戻りアドレスをスタックに配置する最適化されていないコードとは対照的に、無限ループに入るコードを生成できるように思われます。誤用した場合、最終的にはオーバーフローします。

私が持っている他の唯一の考えは、デバッグとスタックトレース印刷のためにスタック上の呼び出しを保存することに関するものです。

考えられる理由の1つは、デバッグとプロファイリングを容易にすることです（TCOを使用すると、親スタックフレームが消え、スタックトレースを理解しにくくなります）。