> 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 нынче один только ман на командлайн читать можно устать :)
зы мне надоели местные модеры, меня они потерли раза три а красования леда по жизни не трогают, давайте может куда-нибудь на ресурс с более комфортной атмосферой, а? я от такой модерации устал, она не способствует конструктивным дискуссиям, вообще совсем.
