Оптимизация GCC упустила возможность

Обе функции slow() и fast() предназначены для выполнения одного и того же, хотя fast() делает это с одним утверждением ветки вместо двух. Я хотел проверить, может ли GCC разбить две ветки на одну. Я пробовал это с GCC 4.4 и 4.7 с различными уровнями оптимизации, такими как -O2, -O3, -Os и -Ofast. Он всегда дает такие же странные результаты:

Действительно, в каждой функции генерируется только одна ветвь. Однако slow() кажется неудовлетворительным: он использует одну дополнительную нагрузку в каждой ветки для aa[0] и bb[0]. Код fast() использует их прямо из памяти в subl, не загружая их сначала в регистр. Таким образом, slow() использует один дополнительный регистр и одну дополнительную инструкцию для каждого вызова.

Простой микро-тест показывает, что вызов fast() один миллиард раз занимает 0,7 секунды, против 1,1 секунды для slow(). Я использую Xeon E5-2690 с частотой 2,9 ГГц.

Почему это должно быть? Можете ли вы каким-либо образом настроить мой исходный код, чтобы GCC выполнял лучшую работу?

Интересно: clang генерирует ветвящиеся условные выражения для slow(), но одну ветвь для fast()! С другой стороны, slow() выполняет три нагрузки (две из которых являются спекулятивными, одна из них не нужна) против двух для fast(). Реализация fast() более "очевидна", и, как и в случае GCC, она короче и использует один меньше регистра.

GCC 4.7 на Mac OS обычно испытывает ту же проблему, что и в Linux. Тем не менее он использует тот же "загружаемый 8 байт, а затем дважды извлекает 4 байта" в качестве Clang в Mac OS. Такой интересный, но не очень актуальный, поскольку исходная проблема испускания subl с двумя регистрами, а не с одной памятью и одним регистром, одинакова на обеих платформах для GCC.

Ответы

Ответ 1

Причина в том, что в исходном промежуточном коде, испускаемом для slow(), загрузка памяти и вычитание находятся в разных базовых блоках:

slow ()
{
  int D.1405;
  int mode.3;
  int D.1402;
  int D.1379;

  # BLOCK 2 freq:10000
  mode.3_5 = mode;
  if (mode.3_5 != 0)
    goto <bb 3>;
  else
    goto <bb 4>;

  # BLOCK 3 freq:5000
  D.1402_6 = aa[1];
  D.1405_10 = aa[0];
  goto <bb 5>;

  # BLOCK 4 freq:5000
  D.1402_7 = bb[1];
  D.1405_11 = bb[0];

  # BLOCK 5 freq:10000
  D.1379_3 = D.1402_17 - D.1405_12;
  return D.1379_3;
}

тогда как в fast() они находятся в одном базовом блоке:

fast ()
{
  int D.1377;
  int D.1376;
  int D.1374;
  int D.1373;
  int mode.1;
  int D.1368;

  # BLOCK 2 freq:10000
  mode.1_2 = mode;
  if (mode.1_2 != 0)
    goto <bb 3>;
  else
    goto <bb 4>;

  # BLOCK 3 freq:3900
  D.1373_3 = aa[1];
  D.1374_4 = aa[0];
  D.1368_5 = D.1373_3 - D.1374_4;
  goto <bb 5>;

  # BLOCK 4 freq:6100
  D.1376_6 = bb[1];
  D.1377_7 = bb[0];
  D.1368_8 = D.1376_6 - D.1377_7;

  # BLOCK 5 freq:10000
  return D.1368_1;
}

GCC полагается на команду, комбинирующую проход, чтобы обрабатывать такие случаи (то есть, по-видимому, не на проходе оптимизации глазок), и объединяет работы в области основного блока. Поэтому вычитание и загрузка объединяются в один insn в fast(), и они даже не рассматриваются для объединения в slow().

Позже, в базовом переупорядочении блока, вычитание в slow() дублируется и перемещается в базовые блоки, которые содержат нагрузки. Теперь у комбайнера есть возможность объединить нагрузку и вычитание, но, к сожалению, пропуск объединения не запускается снова (и, возможно, его невозможно запустить в конце процесса компиляции с уже выделенными жесткими регистрами и т.д.).

Ответ 2

У меня нет ответа относительно того, почему GCC не может оптимизировать код так, как вы этого хотите, но у меня есть способ перестроить ваш код для достижения аналогичной производительности. Вместо того, чтобы организовывать ваш код так, как вы делали это в slow() или fast(), я бы рекомендовал вам определить встроенную функцию, которая возвращает либо aa, либо bb на основе mode, не нуждаясь в ветке:

inline int * xx () { static int *xx[] = { bb, aa }; return xx[!!mode]; }
inline int kwiky(int *xx) { return xx[1] - xx[0]; }
int kwik() { return kwiky(xx()); }

При компиляции GCC 4.7 с -O3:

    movl    mode, %edx
    xorl    %eax, %eax
    testl   %edx, %edx
    setne   %al
    movl    xx.1369(,%eax,4), %edx
    movl    4(%edx), %eax
    subl    (%edx), %eax
    ret

С помощью определения xx() вы можете переопределить auto0() и auto1() следующим образом:

inline int auto0() { return xx()[0]; }
inline int auto1() { return xx()[1]; }

И из этого вы должны увидеть, что slow() теперь компилируется в код, похожий или идентичный kwik().

Ответ 3

Вы пытались изменить параметры компиляторов внутренних компонентов (--param name = value в man-странице). Они не изменяются ни с одного уровня оптимизации (с тремя незначительными исключениями).

Некоторые из них управляют сокращением/дедупликацией кода.

Для некоторых оптимизаций в этом разделе вы можете читать такие вещи, как "большие значения могут экспоненциально увеличивать время компиляции".