한계가 959이지만 960이 아닌 경우 단순 루프가 최적화되는 이유는 무엇입니까?

이 간단한 루프를 고려하십시오.

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

gcc 7 (스냅 샷) 또는 clang (트렁크)을 사용하여 컴파일 -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하는 경우 동일한 루프의 한계 double는 479입니다. 이는 gcc 및 clang의 경우에도 동일합니다.

업데이트 1

gcc 7 (스냅 샷)과 clang (트렁크)은 매우 다르게 동작합니다. 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

완전한 박리에 적합한 루프의 최대 반복 횟수입니다.

insns에 대한 자세한 내용은 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

그 소리

Clang이 실제로 수행하는 작업과 한계를 조정하는 방법을 모르겠지만 관찰 한 바와 같이 unroll pragma로 루프를 표시하여 최종 값을 평가하도록 강제 할 수 있으며 완전히 제거합니다.

#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

Sulthan의 의견을 읽은 후 다음과 같이 추측합니다.

1. 루프 카운터가 일정하고 너무 높지 않은 경우 컴파일러에서 루프를 완전히 언롤합니다.

2. 언 롤링되면 컴파일러는 합 연산이 하나로 그룹화 될 수 있음을 알게됩니다.

어떤 이유로 루프가 풀리지 않으면 (여기서 :로 너무 많은 명령문을 생성 함 1000) 조작을 그룹화 할 수 없습니다.

컴파일러 는 는 1000 개의 문을 언롤하는 것이 단일 추가에 해당한다는 것을 알 있지만 위에서 설명한 1 단계와 2 단계는 두 가지 별도의 최적화이므로 작업을 그룹화 할 수 있는지 알지 못하면 언 롤링의 "위험"을 취할 수 없습니다 (예 : 함수 호출은 그룹화 할 수 없습니다).

참고 : 이것은 모퉁이의 경우입니다. 누가 같은 것을 다시 추가하기 위해 루프를 사용합니까? 이 경우, 가능한 언 롤링 / 최적화 컴파일러에 의존하지 마십시오. 하나의 명령으로 올바른 작동을 직접 작성하십시오.

아주 좋은 질문입니다!

코드를 단순화 할 때 컴파일러가 인라인하려고하는 반복 또는 작업 수에 한계가있는 것 같습니다. Grzegorz Szpetkowski가 문서화 한 것처럼 pragma 또는 명령 행 옵션으로 이러한 한계를 조정할 수있는 컴파일러 특정 방법이 있습니다.

또한 함께 재생할 수 있습니다 Godbolt의 컴파일러 탐색기 : 다른 컴파일러 옵션은 생성 된 코드에 미치는 영향을 비교 gcc 6.2하고 icc 17있는 반면, 960 인라인 여전히 코드를 clang 3.9(기본 Godbolt 구성, 실제로 73 인라인 중지로)하지 않습니다.