> Вообще-то обычно все исходники содержат оптимизацию в системах сборки. Но если кто вкатал свои CFLAGS то как они применятся в билдсистеме это отдельный вопрос. В результате пример какой-то не очень иллюстративный, чтоли: не видно что фактически получил компилер.
> Обычно это -O2.
Сейчас и -O3 в принципе попадается. Он быстрее, но более грабельный.
> Это его побочное действие.
Это "побочное" действие имеет свойство выносить туеву хучу кода.
> Основное как раз inline и прочие подобные оптимизации.
Я так понимаю что он может угрохать всякие сохранения регистров и проч которые как бы нужны, если это совсем независимый модуль вызываемый совсем без допущений. А тут появляется full view как оно вызывается и можно обрубить сохранение регистров которые caller'ам были пофиг. Оно в результате более уже не независимый модуль и как попало вызывать уже не того. Ну и да, инлайнить можно, более информированно чем ранее. А почему нет?
> one. This means, for example, that the inliner is able to
> inline functions in bar.o into functions in foo.o and vice-versa.
Ну да. И как я понимаю перегрузки регистров можно глобально обкусить, т.к. известно кто и как вызывает. А если перегрузки обкусить - объем кода, очевидно, убавится.
> Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации
> и большом количестве мелких функций.
В мелких функциях по идее инлайнинг как раз хорошая штука? Экономия на всяких прологах-эпилогах, никаких сохранений регистров. Сэкономили на сохранениях-восстановлениях, растратили на коде. Выполняется быстрее и полезнее. Если код мелкий то хорошо работает: код не пухнет но ускоряется. И у gcc вроде есть анализы когда и что выгоднее. На больших функциях выгода от инлайна незначительна т.к. оверхед на сопутствующие приседания небольшой, а пухнет сильно. А для мелочи как раз критично - время служебных операций может стать сравнимо с временем в функции. И сишники такое по жизни костыляли #define'ами. Но у них читаемость и форматирование на любителя, и вообще костыль.
