Чому код активно намагається запобігти оптимізації зворотних викликів?

Заголовок запитання може бути дещо дивним, але справа в тому, що, наскільки мені відомо, взагалі немає нічого, що могло б говорити проти оптимізації виклику хвоста. Однак, переглядаючи проекти з відкритим кодом, я вже натрапив на кілька функцій, які активно намагаються перешкодити компілятору виконувати оптимізацію хвостового виклику, наприклад, реалізація 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))цю ідею.

Якщо ви помітите, ця функція в будь-якому випадку просто переходить і переходить до іншої функції, тож це форма батута, про яку я можу тільки подумати, що існує з такою багатослівною назвою для полегшення налагодження. Це було б особливо корисно з огляду на те, що функція викликає покажчик функції, який був зареєстрований з іншого місця, і тому ця функція може не мати доступних символів налагодження.

Зверніть увагу також на інші функції з подібним іменем, які виконують подібні речі - справді схоже, що він допомагає побачити, що трапилось із зворотного сліду. Майте на увазі, що це основний код Mac OS X, і він також відображатиметься у звітах про збої та оброблятиме зразки звітів.

Це лише здогадки, але, можливо, щоб уникнути нескінченного циклу проти вибуху з помилкою переповнення стека.

Оскільки розглянутий метод нічого не поміщає в стек, оптимізація рекурсії зворотного виклику може видавати код, який би входив у нескінченний цикл, на відміну від неоптимізованого коду, який міститиме адресу повернення в стеку який врешті-решт переллється у разі неправильного використання.

Єдина моя думка пов’язана із збереженням викликів у стеку для налагодження та друку стека.

Однією з можливих причин є полегшення налагодження та профілювання (за допомогою TCO кадр батьківського стека зникає, що робить сліди стека важче зрозуміти).