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

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

[ARV]

так ведь вроде бы даже в документации сказано, что ассемблерные вставки с псевдопараметрами в командах (те, которые %1, %2 и т.д.) компилятор "обрамляет" необходимыми командами для занесения в реальные регистры нужных значений и т.п., т.е. ассемблерная вставка вставляется не совсем 1 в 1, а с некими преобразованиями до и после нее как минимум. и второе наблюдение по поводу оптимизатора: asm("nop"); скорее всего исчезнет из кода на этапе оптимизации, а asm volatile ("nop"); останется однозначно - это ли не свидетельствует о том, что ассемблерные вставки подвергаются обработке оптимизатором?