> OK, я не верно сказал. LTO может вынести и функции целиком.

Это его нормальное состояние, я бы сказал.

> Просто затраты (как CPU, так и RAM) на это будут гораздо большими,
> чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections.

А это другой вопрос. В свежих gcc, кстати, LTO основательно разогнали а потребление RAM убавили.

> Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно.

Вот это не знаю, не пробовал такого монстра. На 5-меговой софтине на плюсах лопало около гига памяти, чтоли. Кстати LTO агрессивно оптимизировали по ресурсам в gcc 5.x/6.x, да и скорость компиляции прилично подтянули, особенно на уровнях с оптимизацией.

> цель скорость исполнения - однозначно LTO, но бинарник из-за inline может
> стать и больше.

В среднем по больнице результат таков что прога сдувается по размеру а скорость такая же или чуть лучше. Т.е. я бы больше радовался уменьщению кода.

> Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO.

Насколько я помню -fwhole-program это какой-то хинт LTO-оптимизатору на самом деле, что надо полный анализ по всей программе и можно сделать небезопасные маневры, так что снаружи функции вызывать будет нельзя. Но я не знаю что там на авр сейчас. У убунтуев и дебиана для них почему-то gcc древний, 4.9 чтоли. Для ARM у меня такой же версии как и системный.

> Выигрываем 10% по скорости, проигрываем 900% - 9000% по памяти/кэшу.

Не вижу, опять же. Если проигрыш по кэшу - должны быть просадки скорости как раз? Да и раз кода меньше - то и кэш свободнее? Можно конечно perf-ом потыкаться если принципиально.

А еще - у cortex M кэша нет, микроконтроллеры же.

> ХЗ как оно может оценить пользу от inline, не имея на входе типичных данных.

Прикинув как этот размер кода vs заскипаный на этом пролог/эпилог соотносится?

> Может эта функция вызывается раз в году? А память будет расходоваться всегда.

Опять же - не вижу раздувания кода от LTO.

> к длине функции (можно подрегулировать руками) - если функция больше определенной
> длинны - inline не используется.

Значит мой склероз мне не врет, как-то так.

>> Вы про profile-guided optimization чтоли?
> Да оно.

Вот с ним я не разбирался.

> Зависит от задачи. В теории - имея типичные входные данные компилятор значительно
> лучше сможет выполнить оптимизацию.

Оно как бы да, но возни много. Ну его такое кроме крайних случаев.

> Да, и постоянно новые способы добавляют. С циклами он вообще много интересного
> умеет. При выходе новых версий gcc часто примеры кода показывают и
> как он его хорошо разбирает и перекомпоновывает.

У gcc нынче один только ман на командлайн читать можно устать :)

зы мне надоели местные модеры, меня они потерли раза три а красования леда по жизни не трогают, давайте может куда-нибудь на ресурс с более комфортной атмосферой, а? я от такой модерации устал, она не способствует конструктивным дискуссиям, вообще совсем.