Warum wird eine einfache Schleife optimiert, wenn das Limit 959, aber nicht 960 beträgt?

Betrachten Sie diese einfache Schleife:

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

Wenn Sie mit gcc 7 (Snapshot) oder clang (Trunk) kompilieren, erhalten -march=core-avx2 -OfastSie etwas sehr Ähnliches.

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

Mit anderen Worten, die Antwort wird ohne Schleife auf 960 gesetzt.

Wenn Sie den Code jedoch ändern in:

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

Die produzierte Baugruppe führt tatsächlich die Schleifensumme aus? Zum Beispiel gibt 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

Warum ist das so und warum ist es für clang und gcc genau das gleiche?

Die Grenze für die gleiche Schleife , wenn Sie ersetzen floatmit doubleist 479. Dies ist das gleiche wieder für gcc und Klirren ist.

Update 1

Es stellt sich heraus, dass sich gcc 7 (Schnappschuss) und clang (Trunk) sehr unterschiedlich verhalten. clang optimiert die Loops für alle Limits unter 960, soweit ich das beurteilen kann. gcc hingegen reagiert empfindlich auf den genauen Wert und hat keine Obergrenze. Zum Beispiel es nicht optimiert die Schleife, wenn die Grenze 200 (wie auch viele andere Werte), aber es tut , wenn die Grenze 202 und 20002 (sowie viele andere Werte) ist.

TL; DR

Standardmäßig verhält sich der aktuelle Snapshot GCC 7 inkonsistent, während frühere Versionen aufgrund von PARAM_MAX_COMPLETELY_PEEL_TIMES16 ein Standardlimit haben. Es kann über die Befehlszeile überschrieben werden.

Das Grundprinzip des Limits besteht darin, ein zu aggressives Abrollen der Schleife zu verhindern, das ein zweischneidiges Schwert sein kann .

GCC-Version <= 6.3.0

Die relevante Optimierungsoption für GCC ist -fpeel-loops, die indirekt zusammen mit dem Flag aktiviert wird -Ofast(Schwerpunkt liegt bei mir):

Schält Schleifen, für die genügend Informationen vorhanden sind, die nicht viel rollen (aufgrund von Profilfeedback oder statischer Analyse ). Es wird auch das vollständige Schälen der Schleife aktiviert (dh das vollständige Entfernen von Schleifen mit einer kleinen konstanten Anzahl von Iterationen ).

Aktiviert mit -O3und / oder -fprofile-use.

Weitere Details erhalten Sie durch Hinzufügen von -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

Die Nachricht stammt von /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;
    }

daher try_peel_loopkehrt die Funktion zurück false.

Eine ausführlichere Ausgabe kann erreicht werden mit -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

Es ist möglich, die Grenzen durch Plaing mit max-completely-peeled-insns=nund max-completely-peel-times=nparams zu optimieren :

max-completely-peeled-insns

Die maximale Anzahl von Insns einer vollständig geschälten Schleife.

max-completely-peel-times

Die maximale Anzahl von Iterationen einer Schleife, die für ein vollständiges Schälen geeignet sind.

Weitere Informationen zu Insns finden Sie im GCC Internals Manual .

Zum Beispiel, wenn Sie mit folgenden Optionen kompilieren:

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

dann verwandelt sich Code in:

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

Clang

Ich bin nicht sicher, was Clang tatsächlich tut und wie man seine Grenzen ändert, aber wie ich beobachtet habe, könnten Sie es zwingen, den Endwert zu bewerten, indem Sie die Schleife mit einem Abroll-Pragma markieren , und es wird sie vollständig entfernen:

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

Ergebnisse in:

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

Nachdem ich Sulthans Kommentar gelesen habe, denke ich, dass:

1. Der Compiler rollt die Schleife vollständig ab, wenn der Schleifenzähler konstant (und nicht zu hoch) ist.

2. Sobald es abgewickelt ist, sieht der Compiler, dass die Summenoperationen zu einer zusammengefasst werden können.

Wenn die Schleife aus irgendeinem Grund nicht abgewickelt wird (hier: es würden zu viele Anweisungen mit generiert 1000), können die Operationen nicht gruppiert werden.

Der Compiler konnte feststellen, dass das Abrollen von 1000 Anweisungen eine einzelne Addition darstellt. Die oben beschriebenen Schritte 1 und 2 sind jedoch zwei separate Optimierungen, sodass er nicht das "Risiko" des Abrollens eingehen kann, ohne zu wissen, ob die Vorgänge gruppiert werden können (Beispiel: Ein Funktionsaufruf kann nicht gruppiert werden.

Hinweis: Dies ist ein Eckfall: Wer verwendet eine Schleife, um dasselbe erneut hinzuzufügen? Verlassen Sie sich in diesem Fall nicht darauf, dass der Compiler möglicherweise abrollt / optimiert. Schreiben Sie direkt die richtige Operation in eine Anweisung.

Sehr gute Frage!

Sie scheinen die Anzahl der Iterationen oder Operationen, die der Compiler bei der Vereinfachung des Codes inline zu setzen versucht, begrenzt zu haben. Wie von Grzegorz Szpetkowski dokumentiert, gibt es compilerspezifische Möglichkeiten, diese Grenzwerte mit Pragmas oder Befehlszeilenoptionen zu optimieren.

Sie können auch mit dem Compiler-Explorer von Godbolt spielen , um zu vergleichen, wie sich verschiedene Compiler und Optionen auf den generierten Code auswirken: gcc 6.2und icc 17den Code für 960 weiterhin einbinden, während clang 3.9dies nicht der Fall ist (bei der Standardkonfiguration von Godbolt wird das Inlining bei 73 tatsächlich beendet).