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

[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() компилятор несколько более оптимально перетасовывает окружающие куски кода.
Собственно, вывод мой таков - несмотря на отличную оптимизацию встроенного ассемблера, компилятор не может (или не хочет) применять к нему все возможные методы оптимизации. Возможно, этот вывод поспешен, потому прошу тех, кто придумает куда можно применить вышеуказанные встроенные функции применить их, и рассказать о результатах

[AHTOXA]

Довольно странно в GCC выглядит сочетание volatile asm("nop"), причём IAR такое сочетание не переваривает.

Это потому что IAR не умеет оптимизировать ассемблерные вставки

Потому:

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