Помнится когда-то тут, в этом разделе кажется, было интересное обсуждение, где один из уважаемых (в то время) пользователей приводил интересную статью(помоему даже его собственную) - сравнение размера скомпиллированного кода ARM компилятора в зависимости от структуры файлов программы.
Суть в топике передавался следуюший, есть арм компилятора, один, и есть по разному устроенная тестовая программа, которая делает одно и тоже в разных ее исполнениях. В одном варианте все сделано в одном .c файле, потом разбито на разные .c, потом на .c+.h, потом все это разбросано и для объектов какието параметры менялись... и сравнивался результирующий hex(или чтото еще на выходе). Помнится что самый большой выигрыш был когда все написано в одном файле, но при этом правда код привратился в той еще длины "полотенце"...
Я сейчас не могу найти эту интересную статью, ребята, помогите плиз ее найти. Надеюсь на сторожил раздела форума, вы точно должны помнить, это было длинное интересное обсуждение, гдето в 2008-2010гг.

ИМХО, не актуально, так как современные компиляторы имеют режим multifile compilation.

не, тут мне важно не актуальность, а сама статья, там обсуждалась природа этого явления, вот это то что щас нужно мне

Странно, в 2008 у, например, GCC, ключики combine (все файлы из командной строки компилировать как один файл) и whole-program (и это вся программа, больше ничего нет) ещё существовали (сейчас пропали в пользу LTO). И не надо было бы в портянку соединять.

MS студия, кажется, в режиме финальной компиляции тот же эффект использует, все файлы проекта

Возможно, стоит ещё раз поискать (гуглом) по форуму с применением названий указанных выше ключей, что-то ещё на эту тему найдется.

Природа проста — когда компилятор знает, что это у него всё, что вообще есть, то он при необходимости встраивает по месту те функции, которые иначе находились бы в другом файле, что-то вообще выбрасывает и т.д.

Если в те времена, когда в ходу ARM7TDMI были, то там еще при вызовах stub'ы очень быстро накапливались, а компиляция одним файлом позволяла их минимизировать.

А откуда эта информация? -fwhole-program жив и здоров в 4.7.1, как раз собрал его на днях, занимаюсь оптимизацией под NEON, а combine по умолчанию всегда (Compiling multiple files at once to a single output file mode allows the compiler to use information gained from all of the files when compiling each of them).

А вот вопрос слегка мимо темы - может быть знаете, при сборке gcc в чем разница между CLooG на базе PPL и ISL? опция у configure --enable-cloog-backend=xxxxx, это только на производительность влияет, или на оптимизацию тоже?

То я помню просто года... и там явной привязки к архитектуре не было на сколько я помню, в обзоре рассматривалось в рамках армовского компилятора, и помоему кто-то делал аналогичные тесты в мс-студии и т д

Ну может я с спутал с прямым углом. Вроде где-то проскакивало, что в связи с введением LTO что-то убрали (или это был --relax ?).

Тоже немного мимо темы -- а на avr-gcc 4.7.1 / Ubuntu64 (32) шансы есть?
Всёж набитой рукой это легче.

Да шансы то есть, но тут возникает вопрос - во первых "/Ubuntu" у меня нет и не предвидится, я под центос-ом собираю все, но это все фигня. А во вторых - я не знаю особенностей glibc для авр. Сам же я собираю glibc 2.16 с gnu, но я не уверен, что для авр используется тот же монстр. И вообще не знаю особенностей сборки gcc/glibc для мелко-мелкоконтроллеров. У меня то таки Cortex-A.
с этим, короче, велкам в icq