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

Nate Reinar Windwood
Nate Reinar Windwood
// Все основные компиляторы и так делают 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);
}
-3
рейтинг
7 комментариев
yndx-antoshkka

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

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

yndx-antoshkka
Nate Reinar Windwood

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

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

Nate Reinar Windwood
Andrey

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

Andrey
Саша Зайцев

Лично я против стандартизации оптимизаций. Потому что:
1) Зачем?

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

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

Саша Зайцев
Nate Reinar Windwood

Саша Зайцев, 

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

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

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

Nate Reinar Windwood
Саша Зайцев

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

Саша Зайцев
Саша Зайцев

https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/gCJ1qXLm-dQ

Саша Зайцев
Обновлено 
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).
Все предложения