К вопросу об оптимизации инлайн-ассемблера., Не всё так шоколадно... Опции

[AHTOXA]

Я много раз читал, что инлайн-ассемблер в gcc замечательно оптимизируется. Да и глядя в дизассемблер, убеждался, что это так и есть. Но недавно наткнулся на материал про встроенные функции GCC, и решил их испытать.
Заменил на пробу

Код

INLINE inline byte GetHighPriority(TProcessMap pm)
  {
      dword clzero;
      asm ("clz\t%0, %1": "=r" (clzero): "r" (pm));
      return (31 - clzero);
}

на

Код

INLINE inline byte GetHighPriority(TProcessMap pm)
    {
        return (31 - __builtin_clz(pm));
    }

Собственно код, генерируемый компилятором для этой функции - не поменялся. Но. Размер проекта уменьшился на 40 байт. Это для пяти вызовов данной функции. Это конечно мелочи для проекта на 16 Кб, но тем не менее. Насколько я понял по листингу, при использовании __builtin_clz() компилятор несколько более оптимально перетасовывает окружающие куски кода.
Собственно, вывод мой таков - несмотря на отличную оптимизацию встроенного ассемблера, компилятор не может (или не хочет) применять к нему все возможные методы оптимизации. Возможно, этот вывод поспешен, потому прошу тех, кто придумает куда можно применить вышеуказанные встроенные функции применить их, и рассказать о результатах

[klen]

я всегда думал что инлайн асм вставки для того и придуманы чтоб компиллер их ни прикаких обстоятельствах не трогал - а малоли чего там программер надумал? если былобы не так то (или небыло механизма асм вставок) то некоторые трюки нельзя былобы решить С-кодом вовсе - например crt код для armv4

я считаю что асм вставки тупо вставляются в код компиллером и все слитое предается транслятору асма.
Почему? во первых ВСЯ оптимизация происходит на промежуточном языке RTL, и только потом преобразуется в асм. соответстывенно когда асм вставка попадает в общий код после оптимизации. сам транслятор асма не оптимизирует - не его это дело, да и как? линкер может! например претусить расположение кусков кода(например функций) чтоб увеличить количество быстрых коротких вызовов и переходов если таковые есть в наборе команд проца и тп.

даже более того - встроенные функции - это "теже вставки" котрые уже обернуты в функции С. темболее что Вы утверждаете что исполняемый код не изменился.

эффект о котором Вы говорите скорее всего никак с оптимизацией не связан, я думаю что тут или при линковке чето прилезло или атрибуты у функции __builtin_clz какието такие что заставляют компиллер или линкер делать доп теложвижения, ну например распологать ее в адресном пространстве с хитрым выравниванием или стек для нее както хитро выделить.

Смотреть нада. Прелесть GCC в том что этот вопрос можно просто пронаблюдать по маршруру исходник->RTL->асм->объектник->объектник + либы->выходной elf бинарь -> файл прошивки

глядя на эти промежуточные результаты можно просто увидить различия двух вариантов и понять "кто виноват и чЁ делать"

если я не прав то поправте. ... вот теперь мучить мысль будет "а как ваще asm код можно соптимизировать..."

[AHTOXA]

я всегда думал что инлайн асм вставки для того и придуманы чтоб компиллер их ни прикаких обстоятельствах не трогал

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

эффект о котором Вы говорите скорее всего никак с оптимизацией не связан, я думаю что тут или при линковке чето прилезло или атрибуты у функции __builtin_clz какието такие что заставляют компиллер или линкер делать доп теложвижения, ну например распологать ее в адресном пространстве с хитрым выравниванием или стек для нее както хитро выделить.

Нет, ничего такого. Это инлайн-функция, и код самой функции получается одинаковый с точностью до регистров. То есть, полностью идентичный. Но обрамляющая функция (та, в которую вставляется наша инлайн-функция) - компилится чуть оптимальнее.

------

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

[klen]

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

в принципе выкинуть asm("nop") ничего мешать не должно.


вывод один - все работает так как нада, и мы это ПОНИМАЕМ