为什么在c / c ++中，开关的优化方式与链接方式不同？

Square的以下实现产生了一系列cmp / je语句，就像我期望的链式if语句一样：

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替代方法的目的的switch。因此，尽管值得商bat，但我认为GCC所做的是正确的事情，而clang在其优化方面过于激进。

有人在评论中共享了一个链接，其中clang进行了此优化，并为此生成了基于查找表的代码if-else。当我们用clang将案例数量减少到只有两个（默认）时，会发生一些值得注意的事情。它再次为if和switch生成相同的代码，但是这次，这两者都 切换到比较和移动，而不是查找表方法。这意味着，即使选择开关的叮当声也很容易理解，当案例数较少时，“ if”模式会更加理想！

总而言之，比较器if-else和跳转表的顺序switch-case是编译器倾向于遵循的标准模式，而开发人员在编写代码时往往期望这种标准模式。但是，在某些特殊情况下，某些编译器可能会选择中断这种模式，因为他们认为它提供了更好的优化。其他编译器可能仍然选择遵循该模式，即使显然不是最佳选择，也可以信任开发人员知道他想要什么。两者都是有效的方法，各有其优缺点。

一个可能的理由是，如果较低的值num更有可能（例如始终为0），则为第一个生成的代码可能会更快。所生成的switch代码花费所有时间相等的时间。

根据此表比较最佳情况。有关表格的说明，请参见此答案。

如果num == 0，对于“如果”，您有xor，test，je（带有跳转），重新输入。延迟：1 + 1 +跳跃。但是，xor和test是独立的，因此实际执行速度将比1 + 1周期快。

如果num < 7对于“ switch”，有mov，cmp，ja（无跳转），mov，ret。延迟时间：2 + 1 +无跳跃+ 2。

不导致跳转的跳转指令比导致跳转的指令快。但是，该表未定义跳跃的等待时间，因此我不清楚哪个更好。最后一个可能总是更好，而GCC根本无法对其进行优化。