Tại sao một công tắc không được tối ưu hóa giống như cách xâu chuỗi nếu khác trong c / c ++?

Việc triển khai hình vuông sau đây tạo ra một loạt các câu lệnh cmp / je như tôi mong đợi về một câu lệnh if bị xiềng xích:

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;
    }
}

Và sau đây tạo ra một bảng dữ liệu để trả về:

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;
    }
}

Tại sao gcc không thể tối ưu hóa cái đầu vào cái dưới cùng?

Phân tích để tham khảo: https://godbolt.org/z/UP_igi

EDIT: thật thú vị, MSVC tạo bảng nhảy thay vì bảng dữ liệu cho trường hợp chuyển đổi. Và đáng ngạc nhiên, clang tối ưu hóa chúng cho cùng một kết quả.

Mã được tạo cho switch-case quy ước sử dụng bảng nhảy. Trong trường hợp này, việc trả lại trực tiếp thông qua bảng tra cứu dường như là một sự tối ưu hóa sử dụng thực tế là mọi trường hợp ở đây đều liên quan đến việc trả lại. Mặc dù tiêu chuẩn không đảm bảo cho hiệu ứng đó, tôi sẽ ngạc nhiên nếu trình biên dịch tạo ra một loạt so sánh thay vì bảng nhảy cho trường hợp chuyển đổi thông thường.

Bây giờ đến if-else, nó là hoàn toàn ngược lại. Trong khi switch-casethực thi trong thời gian không đổi, bất kể số lượng nhánh, if-elseđược tối ưu hóa cho số lượng nhánh nhỏ hơn. Ở đây, bạn sẽ mong đợi trình biên dịch về cơ bản tạo ra một loạt các so sánh theo thứ tự mà bạn đã viết chúng.

Vì vậy, nếu tôi đã sử dụng if-elsevì tôi hy vọng hầu hết các cuộc gọi square()sẽ dành cho 0hoặc 1hiếm khi cho các giá trị khác, thì 'tối ưu hóa' điều này để tra cứu bảng thực sự có thể khiến mã của tôi chạy chậm hơn tôi mong đợi, đánh bại mục đích của tôi vì sử dụng ifthay thế của a switch. Vì vậy, mặc dù còn nhiều tranh cãi, tôi cảm thấy GCC đang làm điều đúng đắn và tiếng kêu đang được tích cực quá mức trong việc tối ưu hóa.

Ai đó, trong các bình luận, đã chia sẻ một liên kết trong đó clang thực hiện tối ưu hóa này và cũng tạo mã dựa trên bảng tra cứu if-else. Một cái gì đó đáng chú ý xảy ra khi chúng ta giảm số lượng các trường hợp xuống chỉ còn hai (và một mặc định) với tiếng kêu. Nó một lần nữa tạo mã giống hệt nhau cho cả if và switch, nhưng lần này, chuyển sang so sánh và di chuyển thay vì cách tiếp cận bảng tra cứu, cho cả hai. Điều này có nghĩa là ngay cả những người thích chuyển đổi cũng biết rằng mẫu 'nếu' là tối ưu hơn khi số lượng các trường hợp là nhỏ!

Tóm lại, một chuỗi so sánh if-elsevà bảng nhảy switch-caselà mẫu chuẩn mà trình biên dịch có xu hướng tuân theo và các nhà phát triển có xu hướng mong đợi khi họ viết mã. Tuy nhiên, đối với một số trường hợp đặc biệt, một số trình biên dịch có thể chọn phá vỡ mẫu này khi chúng cảm thấy nó cung cấp tối ưu hóa tốt hơn. Các trình biên dịch khác có thể chỉ chọn bám vào mẫu dù thế nào, ngay cả khi rõ ràng là tối ưu phụ, tin tưởng vào nhà phát triển để biết anh ta muốn gì. Cả hai đều là phương pháp hợp lệ với những ưu điểm và nhược điểm riêng.

Một lý do có thể là nếu các giá trị thấp numcó nhiều khả năng, ví dụ luôn là 0, mã được tạo cho mã đầu tiên có thể nhanh hơn. Mã được tạo cho chuyển đổi mất thời gian bằng nhau cho tất cả các giá trị.

So sánh các trường hợp tốt nhất, theo bảng này . Xem câu trả lời này cho lời giải thích của bảng.

Nếu num == 0, với "nếu" bạn có xor, test, je (có nhảy), ret. Độ trễ: nhảy 1 + 1 +. Tuy nhiên, xor và test là độc lập nên tốc độ thực hiện thực tế sẽ nhanh hơn chu kỳ 1 + 1.

Nếu num < 7, đối với "chuyển đổi", bạn có Mov, cmp, ja (không nhảy), Mov, ret. Độ trễ: 2 + 1 + không nhảy + 2.

Một lệnh nhảy không dẫn đến nhảy sẽ nhanh hơn một lệnh dẫn đến nhảy. Tuy nhiên, bảng không xác định độ trễ cho một bước nhảy, vì vậy tôi không rõ cái nào tốt hơn. Có thể là cái cuối cùng luôn tốt hơn và GCC đơn giản là không thể tối ưu hóa nó.