>> части функций, которые не используются.
> Я проверял на разном софте.
> 1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M.
> Если с LTO собрать, но нигде не вызвать, LTO его выносит
> целиком.OK, я не верно сказал. LTO может вынести и функции целиком. Просто затраты (как CPU, так и RAM) на это будут гораздо большими, чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections. Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно. Если цель уменьшить бинарник - то и gc-sections хватит. Если цель скорость исполнения - однозначно LTO, но бинарник из-за inline может стать и больше.
> Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности,
> ахтунг) dead code вырубается очень даже.
Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO.
>> Зависит от того какой код. Допустим 10% уходило на вызов + сохранение
>> + восстановление регистров. Мы инлайним эту функцию 10-100 раз - код растет.
> Если мы вместо 10% на сохранение потратим это на инлайн - какая,
> собственно, разница?
Выигрываем 10% по скорости, проигрываем 900% - 9000% по памяти/кэшу.
> Единственным достижением станет более шустрый код, где прологи-эпилоги
> заменятся на мелкую функцию. А так там эвристика есть, IIRC, на
> предмет что выгоднее.
ХЗ как оно может оценить пользу от inline, не имея на входе типичных данных. Может эта функция вызывается раз в году? А память будет расходоваться всегда.
> Не знаю как насчет точности но при решении инлайнить или нет если
> не было явного хинта, оценивается размер кода функции vs экономия от
> отсутствия пролога-эпилога и принимается решение, инлайнить или нет.
Если я правильно понял из мана - то в основном все сводится к длине функции (можно подрегулировать руками) - если функция больше определенной длинны - inline не используется.
> Вы про profile-guided optimization чтоли?
Да оно.
> Это несколько другое. Они как-то геморно делаются
> и настолько круто мне, имхо, не надо.
Зависит от задачи. В теории - имея типичные входные данные компилятор значительно лучше сможет выполнить оптимизацию.
> Вполне возможно, но я не знаю насколько анализатор это умеет. Он умеет
> настолько много что всех его умений я не знаю.
Да, и постоянно новые способы добавляют. С циклами он вообще много интересного умеет. При выходе новых версий gcc часто примеры кода показывают и как он его хорошо разбирает и перекомпоновывает.
