> Вообще-то обычно все исходники содержат оптимизацию в системах сборки.

Но если кто вкатал свои 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'ами. Но у них читаемость и форматирование на любителя, и вообще костыль.