Чому оптимізований простий цикл, коли межа становить 959, але не 960?

Розглянемо цю просту петлю:

float f(float x[]) {
  float p = 1.0;
  for (int i = 0; i < 959; i++)
    p += 1;
  return p;
}

Якщо ви компілюєте з gcc 7 (знімок) або clang (trunk), -march=core-avx2 -Ofastви отримаєте щось дуже схоже на.

.LCPI0_0:
        .long   1148190720              # float 960
f:                                      # @f
        vmovss  xmm0, dword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero,zero,zero
        ret

Іншими словами, він просто встановлює відповідь на 960 без циклу.

Однак якщо ви змінили код на:

float f(float x[]) {
  float p = 1.0;
  for (int i = 0; i < 960; i++)
    p += 1;
  return p;
}

Вироблена збірка фактично виконує суму циклу? Наприклад, clang дає:

.LCPI0_0:
        .long   1065353216              # float 1
.LCPI0_1:
        .long   1086324736              # float 6
f:                                      # @f
        vmovss  xmm0, dword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero,zero,zero
        vxorps  ymm1, ymm1, ymm1
        mov     eax, 960
        vbroadcastss    ymm2, dword ptr [rip + .LCPI0_1]
        vxorps  ymm3, ymm3, ymm3
        vxorps  ymm4, ymm4, ymm4
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
        vaddps  ymm0, ymm0, ymm2
        vaddps  ymm1, ymm1, ymm2
        vaddps  ymm3, ymm3, ymm2
        vaddps  ymm4, ymm4, ymm2
        add     eax, -192
        jne     .LBB0_1
        vaddps  ymm0, ymm1, ymm0
        vaddps  ymm0, ymm3, ymm0
        vaddps  ymm0, ymm4, ymm0
        vextractf128    xmm1, ymm0, 1
        vaddps  ymm0, ymm0, ymm1
        vpermilpd       xmm1, xmm0, 1   # xmm1 = xmm0[1,0]
        vaddps  ymm0, ymm0, ymm1
        vhaddps ymm0, ymm0, ymm0
        vzeroupper
        ret

Чому це так і чому це точно так само для clang та gcc?

Обмеження для тієї ж петлі, якщо ви заміните floatна double479. Це те саме для gcc та clang знову.

Оновлення 1

Виявляється, що gcc 7 (знімок) і clang (trunk) ведуть себе дуже по-різному. Наскільки я можу сказати, "clang" оптимізує цикли на всі межі менше 960. gcc, з іншого боку, чутливий до точного значення і не має верхньої межі. Наприклад, він не оптимізує цикл, коли межа становить 200 (як і багато інших значень), але він робить, коли межа становить 202 та 20002 (як і багато інших значень).

TL; DR

За замовчуванням поточний знімок GCC 7 веде себе непослідовно, тоді як для попередніх версій встановлено обмеження за замовчуванням PARAM_MAX_COMPLETELY_PEEL_TIMES, яке становить 16. Це може бути відмінено з командного рядка.

Обґрунтування межі полягає в тому, щоб запобігти розгортанню занадто агресивного циклу, що може бути мечем з двома кінцями .

Версія GCC <= 6.3.0

Відповідним варіантом оптимізації для GCC є -fpeel-loops, який увімкнено опосередковано разом із прапором -Ofast(акцент - мій):

Знімає петлі, для яких є достатньо інформації, що вони не сильно котяться (з відгуків профілю або статичного аналізу ). Він також вмикає повне лущення циклу (тобто повне видалення петель з невеликою постійною кількістю ітерацій ).

Увімкнено за допомогою -O3та / або -fprofile-use.

Більш детальну інформацію можна отримати, додавши -fdump-tree-cunroll:

$ head test.c.151t.cunroll 

;; Function f (f, funcdef_no=0, decl_uid=1919, cgraph_uid=0, symbol_order=0)

Not peeling: upper bound is known so can unroll completely

Повідомлення від /gcc/tree-ssa-loop-ivcanon.c:

if (maxiter >= 0 && maxiter <= npeel)
    {
      if (dump_file)
        fprintf (dump_file, "Not peeling: upper bound is known so can "
         "unroll completely\n");
      return false;
    }

отже, try_peel_loopфункція повертається false.

Більш докладний вихід можна досягти за допомогою -fdump-tree-cunroll-details:

Loop 1 iterates 959 times.
Loop 1 iterates at most 959 times.
Not unrolling loop 1 (--param max-completely-peeled-times limit reached).
Not peeling: upper bound is known so can unroll completely

Можна налаштувати межі, граючи з max-completely-peeled-insns=nі max-completely-peel-times=nпарами:

max-completely-peeled-insns

Максимальна кількість розсилок повністю очищеної петлі.

max-completely-peel-times

Максимальна кількість ітерацій петлі, яка підходить для повного відшаровування.

Щоб дізнатися більше про відвідувачі, ви можете ознайомитись з Посібником з внутрішніх справ GCC .

Наприклад, якщо ви компілюєте такі варіанти:

-march=core-avx2 -Ofast --param max-completely-peeled-insns=1000 --param max-completely-peel-times=1000

тоді код перетворюється на:

f:
        vmovss  xmm0, DWORD PTR .LC0[rip]
        ret
.LC0:
        .long   1148207104

Кланг

Я не впевнений, що насправді робить Кланг і як налаштувати його межі, але, як я зауважив, ви можете змусити його оцінити остаточне значення, позначивши цикл розгортанням прагми , і це повністю видалить:

#pragma unroll
for (int i = 0; i < 960; i++)
    p++;

результати в:

.LCPI0_0:
        .long   1148207104              # float 961
f:                                      # @f
        vmovss  xmm0, dword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero,zero,zero
        ret

Прочитавши коментар Султана, я думаю, що:

1. Компілятор повністю розкручує цикл, якщо лічильник циклу постійний (і не надто високий)

2. Після його розгортання компілятор бачить, що операції з сумою можна згрупувати в одну.

Якщо цикл з якихось причин не розкручується (тут: він створив би занадто багато операторів 1000), операції неможливо згрупувати.

Компілятор міг бачити, що розгортання 1000 операторів становить одне додавання, але описані вище кроки 1 та 2 - це дві окремі оптимізації, тому він не може ризикувати розгортанням, не знаючи, чи можна згрупувати операції (наприклад: виклик функції неможливо згрупувати).

Примітка. Це кутовий випадок: хто використовує цикл, щоб знову додати те саме? У цьому випадку не покладайтеся на можливий розгортання / оптимізацію компілятора; безпосередньо написати належну операцію в одній інструкції.

Дуже гарне запитання!

Ви, здається, досягли обмеження кількості ітерацій або операцій, які компілятор намагається ввести, спрощуючи код. Як задокументовано Гжегожем Щепетковським, існують специфічні для компілятора способи налаштування цих меж за допомогою прагм чи параметрів командного рядка.

Ви також можете пограти з компілером Godbolt's Compiler Explorer, щоб порівняти, як різні компілятори та параметри впливають на створений код: gcc 6.2і icc 17все-таки вбудований код для 960, тоді як clang 3.9це не так (за конфігурацією Godbolt за замовчуванням, він фактично припиняє вкладку на 73).