Добавить Tail Call Optimization в стандарт

[apolukhin]

Перенос предложения: голоса +1, -4 Автор идеи: Nate Reinar Windwood

Все основные компиляторы и так делают TCO, так почему бы не гарантировать это стандартом?

// Все основные компиляторы и так делают TCO,
// так почему бы не гарантировать это стандартом?

// Это позволит писать, например, вот так и точно знать,
// что это будет работать не медленнее императивного варианта:

constexpr int fibonacci(int n, int a = 0, int b = 1)
{
    if (n == 0) return a;
    if (n == 1) return b;

    return (n < 0)
        ? fibonacci(n + 1, b - a, a)
        : fibonacci(n - 1, b, a + b);
}
``

[apolukhin]

yndx-antoshkka, 27 июля 2018, 11:53 Обычно, в стандарт языка не добавляют описание оптимизаций, т.к. это связывает руки разработчикам компиляторов и заставляет их делать подобные оптимизации там, где им это делать не хотелось бы (например на -O0).

Если вы хотите за это взяться, то учтите, что вам придётся описать поведение оптимизации в constexpr контексте, описать scopeы переменных на случай исключения и тщательно описать саму трансформацию (когда происходит, как трансформирует, как влияет на области видимости, как влияет на инстанциацию шаблонных функций и т.п.)

Nate Reinar Windwood, 8 августа 2018, 21:58 yndx-antoshkka, а можно упомянуть в стандарте наличие как минимум двух уровней оптимизации, и при нулевом не требовать оптимизаций?

Окей, кажется, я пока не готов за это взяться :-/

Andrey, 27 июля 2018, 12:31 Сейчас эта оптимизация выполняется только когда результат функции вовзращается через регистр (по крайней мере так в GCC), что в соответсвии с ABI возможно только для trivially copyable типов маленького размера. Соответственно, чтобы сделать эту оптимизацию обязательной, надо как минимум зафиксировать, когда результат функции вовзращается через регистр, что сделать очень сложно (у всех разный ABI, calling convention, ...).

Саша Зайцев, 27 июля 2018, 23:13 Лично я против стандартизации оптимизаций. Потому что: 1) Зачем?

2) А может компилятор не всегда хочет делать данную оптимизацию? Как тогда выкручиваться? Грубо говоря, только мешать будем компилятору

3) Ввод в Стандарт оптимизаций - штука неоднозначная. Потому что непонятно, что стоит туда пихать, а что нет. Гарантированный inline, девиртуализация в тривиальных кейсах, векторизация, разворачивание циклов и много чего ещё - когда стоит остановиться?

Nate Reinar Windwood, 8 августа 2018, 22:09 Саша Зайцев,

1. В данном случае — чтобы можно было писать в функциональном стиле и не бояться, что это будет супермедленно. Да и вообще в целом чтобы не думать о компиляторе и полагаться только на то, что гарантировано стандартом.

2. А можно упомянуть в стандарте наличие как минимум двух уровней оптимизации, и при нулевом не требовать оптимизаций?

3. Ну, во-первых, TCO в зависимости от стиля программирования может превратить нерабочую программу в оптимальную, так что это довольно критичная оптимизация. А во-вторых, зачем останавливаться? Это же хорошо — меньше полагаться на конкретный компилятор и больше — на стандарт.

Саша Зайцев, 8 августа 2018, 22:19 Nate Reinar Windwood, 1) Не хотите бояться супермедленности - пишите в нормальном стиле. Хотите функционально - верьте компилятору и надейтесь. 2) В Сатндарте не упоминают никакие уровни оптимизации, так как это вообще Стандарта языка не касается 3) Конечно может. А оптимизации в Стандарте не описывают, потому что очень сложно описать сами оптимизации. Просто подумайте, как вы опишите разворачивание циклов, векторизацию? А у нас много целевых платформ, и на разных платформах разные оптимизации могут иметь разную эффективность, а некоторые вообще работать не будут.

Nate Reinar Windwood, 12 декабря 2018, 23:09 Саша Зайцев,

1. А почему функциональный стиль вдруг стал ненормальный, учитывая, что C++ мультипарадигменный язык и сейчас довольно сильно в сторону функциональщины развивается?

Саша Зайцев, 31 июля 2018, 15:39 https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/gCJ1qXLm-dQ