einpoklum
einpoklum

Reputation: 131395

Do compilers optimize switches differently than long if-then-else chains?

Suppose I have N different integral values known at compile time, V_1 through V_N. Consider the following structures:

const int x = foo();
switch(x) {
case V_1: { /* commands for V_1 which don't change x */ } break;
case V_2: { /* commands for V_1 which don't change x */ } break;
/* ... */
case V_N: { /* commands for V_1 which don't change x */ } break;
}

versus

const int x = foo();
if      (x == V_1) { /* commands for V_1 which don't change x */ }
else if (x == V_2) { /* commands for V_2 which don't change x */ }
else ...
else if (x == V_N) { /* commands for V_N which don't change x */ }

Do modern C++ compilers treat these differently? That is, do they apply different potential optimization to these code structures? Or do they "canonicalize" them to the same for, then decide on optimizations (such as whether to form a jump table or not)?

Notes:

Upvotes: 5

Views: 644

Answers (1)

SergeyA
SergeyA

Reputation: 62553

Ironically, that is exactly the test I did just a couple of days back for most recent compilers. As it happened, with latest compilers, clang produces the same assembly for switch and if - for small number of cases (below 5) it produces a bunch of direct conditional jumps, while for 5 or more cases it does an indirect table jump.

On the other hand, gcc treats those differently: it converts switch to indirect table jump, while a series of if statements remain a series of conditional direct jumps.

It is also worth noting, that if switch case has "holes" in it (i.e. possible values for control variable which are not covered by case label), it can be still converted into series of conditional direct jumps or indirect table jump, but I wasn't able to figure out the exact formula.

Here is some play code: https://gcc.godbolt.org/z/Lll1Kd

Upvotes: 4

Related Questions