Які, якщо такі, компілятори C ++ роблять оптимізацію хвостової рекурсії?

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

Чи роблять цю оптимізацію будь-які компілятори C ++? Чому? Чому ні?

Як мені сказати компілятору зробити це?

• Для MSVC: /O2або/Ox
• Для GCC: -O2або-O3

Як щодо перевірки, чи компілятор це зробив у певному випадку?

• Для MSVC увімкніть вихід PDB, щоб він міг відстежувати код, а потім перевірити код
• Для GCC ..?

Я все одно прийму пропозиції щодо того, як визначити, чи певна функція оптимізована таким чином компілятором (хоча я вважаю заспокійливим, що Конрад каже мені прийняти це)

Завжди можна перевірити, чи робить це компілятор взагалі, зробивши нескінченну рекурсію і перевіривши, чи це призводить до нескінченного циклу або переповнення стека (я це зробив з GCC і виявив, що -O2це достатньо), але я хочу бути здатний перевірити певну функцію, яку я знаю, все одно припиниться. Я хотів би простий спосіб перевірити це :)

Після деяких випробувань я виявив, що деструктори руйнують можливість зробити цю оптимізацію. Іноді може бути вартим того, щоб змінити обсяг певних змінних та тимчасових періодів, щоб переконатися, що вони виходять із сфери застосування перед початком оператора return.

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

Усі поточні компілятори мейнстріму досить добре виконують оптимізацію хвостових викликів (і роблять це вже більше десяти років), навіть для взаємно рекурсивних викликів, таких як:

int bar(int, int);

int foo(int n, int acc) {
    return (n == 0) ? acc : bar(n - 1, acc + 2);
}

int bar(int n, int acc) {
    return (n == 0) ? acc : foo(n - 1, acc + 1);
}

Дозволити компілятору зробити оптимізацію просто: Просто увімкніть оптимізацію для швидкості:

• Для MSVC використовуйте /O2або /Ox.
• Для GCC, Clang та ICC використовуйте -O3

Простий спосіб перевірити, чи зробив компілятор оптимізацію, - це здійснити виклик, який інакше призведе до переповнення стека - або перегляд результатів складання.

Як цікава історична примітка, оптимізація хвостових викликів для C була додана до GCC під час дипломної роботи Марка Пробста. У дипломній роботі описані деякі цікаві застереження щодо реалізації. Варто прочитати.

gcc 4.3.2 повністю вказує цю функцію (хитра / тривіальна atoi()реалізація) main(). Рівень оптимізації є -O1. Я помічаю, якщо я зіграю з цим (навіть змінюючи його staticна extern, рекурсія хвоста проходить досить швидко, тому я не залежав би від цього на правильність програми.

#include <stdio.h>
static int atoi(const char *str, int n)
{
    if (str == 0 || *str == 0)
        return n;
    return atoi(str+1, n*10 + *str-'0');
}
int main(int argc, char **argv)
{
    for (int i = 1; i != argc; ++i)
        printf("%s -> %d\n", argv[i], atoi(argv[i], 0));
    return 0;
}

Як і очевидне (компілятори не роблять подібного роду оптимізацію, якщо ви цього не вимагаєте), в деструкторах C ++: є складність щодо оптимізації хвостових викликів.

Дано щось на кшталт:

   int fn(int j, int i)
   {
      if (i <= 0) return j;
      Funky cls(j,i);
      return fn(j, i-1);
   }

Компілятор не може (в цілому) хвостовим викликом оптимізувати це, оскільки йому потрібно викликати деструктор cls після повернення рекурсивного виклику.

Іноді компілятор може побачити, що у деструктора немає зовнішніх видимих ​​побічних ефектів (тому це можна зробити рано), але часто він не може.

Особливо поширеною формою цього є те, де Funkyнасправді є std::vectorабо подібне.

Більшість компіляторів не роблять оптимізації для складання налагодження.

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

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