Во внутреннем представлении он теперь на виртуальном регистре. При распределении попадает на оптимальный (по мнению распределителя) регистр — это могут быть и разные регистры в разных частях функции или даже стек. Главное что теперь перед горячим циклом EBX можно взять в оборот.
Есть. Сейчас не векторизует. Есть патч, чтобы векторизовал. Проблема известная и фикс скорее всего будет в 5.0.
Так как проблема локально в Cilk Plus части, то скорее всего будет и бекпорт в 4.9.
Cilk Plus как и OMP 4.0 сами по себе не могут векторизовать код — нужна поддержа внутри компилятора.
Даже при установке «pragma (omp) simd» перед циклом разные компиляторы будут вести себя по разному. Векторизовать код можно оптимально, а можно и не очень. Именно для того чтобы векторизовать оптимально и развиваются техники векторизации. Данная статья описывает улучшения техники векторизации в GCC для x86. Cilk Plus и OMP 4.0 помогут указать где эти улучшения конкретно применять.
Ну есть еще такой неявный источник как комментарии maintainer-ов при submit-е патча. По сути лишь они детально разбираются во всех уголках GCC. Почти всегда они открыты для помощи.
Подтверждаю. Достаточно подать GCC "-masm=intel". В целом дело вкуса. Когда работаешь с «X86 Software Developers Manual» проще понимать Intel asm. Для остальной работы мне тоже больше по вкусу AT&T.
Добавить поддержку в софте — одно. Добавить инфраструктуру и людей это много сложнее. GNU продукты это не только gcc. Не зря все бьются за совместимость с gcc.
Если Вам нужно сравнить gcc и clang, то подойдет и что-нибудь другое. Прирост gcc от архитектурных оптимизаций будет другой, но в целом картина будет схожа.
Да особых отличий не должно быть. Будут те же опции и выводы. Ну разве что "-x32" потенциально добавится для экономии памяти и регистров. Только для x86_64 размеры намного реже критичны.
Кстати, -mfpmath=sse не круто с точки зрения размера
Согласен. Особенно если использовать встроеный sin, например. Правда, и вещественная арифметика почти не представлена в тех приложения, что были использованны для получения цифр (для мобилных приложений более свойственны целочисленные вычисления, вещественные завернуты в библиотеки).
«хороший код» реально писать, если пишешь его в одиночку и с нуля. Зачастую некоторые интерфейсы уже написаны.
Грубая сила предполагает высокую скорость компиляции или наличие крутого сервера.
Что-то мне подсказывает, что 90% эффекта от «грубой силы» можно добиться «здравым смыслом».
Про архивацию — правда, но уже не про GCC/LD.
В статье обозначен вывод, что польза от "-flto", с точки зрения размера кода, в основном засчет удаления неиспользуемых функций. То есть можно воспользоваться "-ffunction-sections -Wl,--gc-sections".
"-Os -flto" редкое сочетание, может оказаться и не надежным.
К сожалению, нет под рукой GCC под Windows. Подскажите опции при которых секция .text была минимальна (принимая в расчет только оптимизации самого .text). Посмотрю в каком месте GCC можно подкрутить.
Так как проблема локально в Cilk Plus части, то скорее всего будет и бекпорт в 4.9.
Даже при установке «pragma (omp) simd» перед циклом разные компиляторы будут вести себя по разному. Векторизовать код можно оптимально, а можно и не очень. Именно для того чтобы векторизовать оптимально и развиваются техники векторизации. Данная статья описывает улучшения техники векторизации в GCC для x86. Cilk Plus и OMP 4.0 помогут указать где эти улучшения конкретно применять.
Согласен. Особенно если использовать встроеный sin, например. Правда, и вещественная арифметика почти не представлена в тех приложения, что были использованны для получения цифр (для мобилных приложений более свойственны целочисленные вычисления, вещественные завернуты в библиотеки).
Грубая сила предполагает высокую скорость компиляции или наличие крутого сервера.
Что-то мне подсказывает, что 90% эффекта от «грубой силы» можно добиться «здравым смыслом».
Про архивацию — правда, но уже не про GCC/LD.
"-Os -flto" редкое сочетание, может оказаться и не надежным.