c / c ++에 다른 경우 스위치가 체인과 같은 방식으로 최적화되지 않는 이유는 무엇입니까?

다음 square 구현은 체인 if 문과 같이 cmp / je 문을 생성합니다.

int square(int num) {
    if (num == 0){
        return 0;
    } else if (num == 1){
        return 1;
    } else if (num == 2){
        return 4;
    } else if (num == 3){
        return 9;
    } else if (num == 4){
        return 16;
    } else if (num == 5){
        return 25;
    } else if (num == 6){
        return 36;
    } else if (num == 7){
        return 49;
    } else {
        return num * num;
    }
}

그리고 다음은 반환 할 데이터 테이블을 생성합니다.

int square_2(int num) {
    switch (num){
        case 0: return 0;
        case 1: return 1;
        case 2: return 4;
        case 3: return 9;
        case 4: return 16;
        case 5: return 25;
        case 6: return 36;
        case 7: return 49;
        default: return num * num;
    }
}

왜 gcc가 상단을 하단으로 최적화 할 수 없습니까?

참조를위한 분해 : https://godbolt.org/z/UP_igi

편집 : 흥미롭게도 MSVC는 스위치 케이스의 데이터 테이블 대신 점프 테이블을 생성합니다. 놀랍게도, clang은 그것들을 동일한 결과로 최적화합니다.

일반적으로 생성 된 코드 switch-case는 점프 테이블을 사용합니다. 이 경우, 룩업 테이블을 통한 직접 리턴은 여기에있는 모든 경우에 리턴이 포함된다는 사실을 이용하여 최적화하는 것 같습니다. 표준이 그 효과를 보장하지는 않지만, 컴파일러가 일반적인 스위치 케이스에 대한 점프 테이블 대신 일련의 비교를 생성한다면 놀랄 것입니다.

지금오고 if-else, 그것은 정반대입니다. switch-case분기 수에 관계없이 일정한 시간에 실행되는 동안 if-else더 적은 수의 분기에 최적화됩니다. 여기에서 컴파일러는 기본적으로 일련의 비교를 작성한 순서대로 생성 할 것으로 예상합니다.

나는 사용했다 그렇다면 if-else나는 대부분의 호출에 대한 기대 때문에 square()이 될하는 0또는 1드물게 다른 값을 후 실제로 내 코드가 사용에 대한 내 목적을 물리 치고, 느린 내가 예상 한 것보다 실행할 수있는 원인 테이블 - 조회에이 '최적화' if대신 (A)의 switch. 따라서 논쟁의 여지가 있지만 GCC가 올바른 일을하고 있으며 clang이 최적화에 지나치게 공격적이라고 생각합니다.

어떤 사람은 의견에서 clang 이이 최적화를 수행 하고 조회 테이블 기반 코드를 생성 하는 링크를 공유했습니다 if-else. clang을 사용하여 사례 수를 2 개 (및 기본값)로 줄이면 주목할만한 일이 발생합니다. if와 switch 모두 동일한 코드를 다시 생성하지만 이번에 는 lookup-table 방식 대신 비교 및 이동으로 전환됩니다 . 즉, 스위치 선호 클랜도 케이스 수가 적을 때 'if'패턴이 더 최적이라는 것을 알고 있습니다!

요약하면, 일련의 비교 if-else및 점프 테이블 switch-case은 컴파일러가 따르는 경향이 있고 개발자가 코드를 작성할 때 기대하는 표준 패턴입니다. 그러나 특정 특수한 경우 일부 컴파일러는 더 나은 최적화를 제공한다고 생각되는 위치에서이 패턴을 중단하기로 선택할 수 있습니다. 다른 컴파일러는 아마도 최적이 아닌 경우에도 패턴을 고수하여 개발자가 원하는 것을 알도록 할 수 있습니다. 둘 다 고유 한 장단점이있는 유효한 접근 방식입니다.

가능한 근거 중 하나는 값이 낮을수록 ( num예 : 항상 0) 첫 번째 코드에 대해 생성 된 코드가 더 빠를 수 있다는 것입니다. 스위치에 대해 생성 된 코드는 모든 값에 대해 동일한 시간이 걸립니다.

에 따라, 최적의 사례를 비교 이 표 . 표에 대한 설명은 이 답변 을 참조하십시오 .

만약 num == 0에 당신이 XOR, 테스트, (점프) JE이 "만일", RET. 지연 시간 : 1 + 1 + 점프. 그러나 xor와 test는 독립적이므로 실제 실행 속도는 1 + 1 사이클보다 빠릅니다.

만약 num < 7, 당신이 MOV, CMP, (점프없이) JA, MOV, RET이 "스위치"를 참조하십시오. 지연 시간 : 2 + 1 + 점프 없음 + 2.

점프하지 않는 점프 명령이 점프하는 명령보다 빠릅니다. 그러나 테이블은 점프에 대한 대기 시간을 정의하지 않으므로 어느 것이 더 나은지 명확하지 않습니다. 마지막 것이 항상 더 좋을 수 있으며 GCC는 단순히 그것을 최적화 할 수 없습니다.