Sınır 959 iken 960 değilken neden basit bir döngü optimize edilir?

Şu basit döngüyü düşünün:

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

Gcc 7 (anlık görüntü) veya clang (trunk) ile derlerseniz, -march=core-avx2 -Ofastçok benzer bir şey elde edersiniz.

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

Başka bir deyişle, cevabı döngü yapmadan 960'a ayarlar.

Ancak kodu şu şekilde değiştirirseniz:

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

Üretilen derleme aslında döngü toplamını gerçekleştirir Örneğin clang şunu verir:

.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

Bu neden ve neden clang ve gcc için tamamen aynı?

Aynı döngü sınırı değiştirirseniz floatile doublebu yine gcc ve clang için aynıdır 479. olduğunu.

Güncelleme 1

Gcc 7'nin (anlık görüntü) ve clang'ın (trunk) çok farklı davrandığı ortaya çıktı. clang, anlayabildiğim kadarıyla 960'ın altındaki tüm sınırlar için döngüleri optimize ediyor. gcc ise tam değere duyarlıdır ve bir üst limiti yoktur. Örneğin o etmez sınırı 200 olduğu zaman döngü üzerinden duruma (aynı zamanda pek çok diğer değerler) ama yapar sınır 202 ve 20002 (aynı zamanda pek çok diğer değerleri) olduğunda.

TL; DR

Varsayılan olarak, mevcut anlık görüntü GCC 7 tutarsız davranır, önceki sürümlerde PARAM_MAX_COMPLETELY_PEEL_TIMESise 16 olan varsayılan sınır vardır. Bu, komut satırından geçersiz kılınabilir.

Sınırın mantığı, iki ucu keskin bir kılıç olabilecek çok agresif döngü açılmasını önlemektir .

GCC sürümü <= 6.3.0

GCC için ilgili optimizasyon seçeneği -fpeel-loops, bayrakla birlikte dolaylı olarak etkinleştirilen -Ofast(vurgu benimdir):

Çok fazla yuvarlanmadıkları yeterli bilginin bulunduğu (profil geri bildirimi veya statik analizden ) döngüleri soyar . Ayrıca, tam döngü soyulmasını da açar (yani , sabit sayıda yineleme ile döngülerin tamamen kaldırılması ).

-O3Ve / veya ile etkinleştirildi -fprofile-use.

Ekleyerek daha fazla ayrıntı elde edilebilir -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

Mesaj şu kişiden geliyor /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;
    }

dolayısıyla try_peel_loopfonksiyon geri döner false.

Daha ayrıntılı çıktıya aşağıdakilerle ulaşılabilir -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=nVe max-completely-peel-times=nparams ile limitleri değiştirmek mümkündür:

max-completely-peeled-insns

Tamamen soyulmuş bir döngünün maksimum insn sayısı.

max-completely-peel-times

Tam soyulmaya uygun bir döngünün maksimum yineleme sayısı.

İnsns hakkında daha fazla bilgi edinmek için GCC Internals Manual'a başvurabilirsiniz .

Örneğin, aşağıdaki seçeneklerle derlerseniz:

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

sonra kod şuna dönüşür:

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

çınlama

Clang'ın gerçekte ne yaptığından ve sınırlarını nasıl değiştireceğinden emin değilim, ancak gözlemlediğim gibi, döngüyü unroll pragma ile işaretleyerek onu nihai değeri değerlendirmeye zorlayabilirsiniz ve bu onu tamamen kaldıracaktır:

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

sonuçlanır:

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

Sulthan'ın yorumunu okuduktan sonra sanırım:

1. Derleyici, döngü sayacı sabitse (ve çok yüksek değilse) döngüyü tamamen açar

2. Bir kez kaydı kaldırıldığında, derleyici toplam işlemlerinin tek bir işlemde gruplanabileceğini görür.

Döngü herhangi bir nedenle açılmazsa (burada: ile çok fazla ifade oluşturur 1000), işlemler gruplanamaz.

Derleyici olabilir 1000 tabloların göz önüne sermek tek ek yaratmak anlamına geldiği görüyorum ama adım 1 ve 2 bu işlemler gruplandırılabilir if (örnek bilmeden unrolling ait "risk" alamaz böylece yukarıdaki iki ayrı optimizasyonları de tarif edilmiştir: bir işlev çağrısı gruplanamaz).

Not: Bu bir köşe vakası: Aynı şeyi tekrar eklemek için bir döngüyü kim kullanır? Bu durumda, derleyicinin olası unroll / optimizasyonuna güvenmeyin; doğrudan doğru işlemi bir talimatta yazın.

Çok güzel soru!

Derleyicinin kodu basitleştirirken satır içi yapmaya çalıştığı yineleme veya işlem sayısında bir sınıra ulaşmış görünüyorsunuz. Grzegorz Szpetkowski tarafından belgelendiği gibi, bu sınırları pragmalar veya komut satırı seçenekleriyle ayarlamanın derleyiciye özgü yolları vardır.

Ayrıca, farklı derleyicilerin ve seçeneklerin üretilen kodu nasıl etkilediğini karşılaştırmak için Godbolt's Compiler Explorer ile de oynayabilirsiniz : gcc 6.2ve icc 17yine de 960 için kodu satır içi, oysa clang 3.9değil (varsayılan Godbolt yapılandırmasıyla, aslında satır içi 73'te durur).