Blog post traces how GCC lowers switch statements beyond jump tables
A detailed technical writeup dissects GCC's switch-statement optimizations, including bitset-based lowering, and gains traction on Hacker News and Lobsters.
What to know
- GCC can lower a switch statement into a jump table, a branch (comparison) sequence, or a bitset test, choosing based on an internal profitability heuristic.
- The post finds the jump-table threshold is roughly eight table entries per case label, and that the heuristic actually counts comparisons rather than raw case labels when cases are contiguous.
- A worked example shows gcc emitting a bit-test instruction keyed to a constant (2753205) that encodes ASCII case values as a bitset instead of using cmp or jump-table code.
- The article walks through GCC's actual source (pass_lower_switch, analyze_switch_statement) to explain the mechanism, and has propagated from Lobsters to Hacker News's front page with no substantive discussion yet in the evidence.
xoranth.net author Blog authorGCC (GNU Compiler Collection) developers Compiler maintainers
How it unfolded 3 developments, newest first · click a bar or a number to jump articlesposts
-
3
Automated accounts mirror the HN submission on Mastodon
Bot accounts (h4ckernews@mastodon.social and hkrn@mstdn.social) repost the Hacker News link and title to Mastodon shortly after the HN submission.
-
> The compiler is able to implement them as a decision tree (even though maybe it shouldn't)Sometimes a decision tree is definitely faster. When developing System.HashCode, I used a switch (which I think always compiles to a jump table in .Net - at least my case did back then). This was for the trailing non-block sized bytes, I think. It was…
2 more of the top 3 · 12 posts in this stretch
-
H
Switch Lowering in GCC L: https:// xoranth.net/gcc-switch/ C: https:// news.ycombinator.com/item?id=5 0314085 posted on 2026.10.31 at 04:02:26 (c=0, p=4)
-
I once played around with having a very large switch statement (all mac address manufactors in one switch) and in LLVM it would compile fine without optimizations, but if I turned optimizations on it would just spend around half an hour compiling it. I think GCC did it faster, but its been some time ago since I did it. In the Rust crate that was…
-
-
2
Post reaches Hacker News front page
The same article is submitted to Hacker News by signa11 and appears on the HN front page RSS feed, with an associated comments thread.
-
1
Blog post on GCC switch lowering posted to Lobsters
The xoranth.net article explaining GCC's switch-statement lowering strategies (jump tables, branch sequences, bitset tests) is submitted to Lobsters by user jo3_l.
“gcc considers the threshold to be around eight jump table entries per case label.”
— xoranth.net (blog author), blog author · source -
2 outlets Switch Lowering in GCC
first by HN Best, 12d ago · also HN Frontpage
-
What people are saying 9 voices from 2 sites · best of 12 · verbatim
- Oct 31
-
I assume 34 in the compact_7() one was supposed to be 35, and edx was supposed to be used at some point in the bittest() one (unless i'm missing something lol)
-
H
Switch Lowering in GCC Link: https:// xoranth.net/gcc-switch/ Discussion: https:// news.ycombinator.com/item?id=5 0314085
-
Reducing the range would have been useful to reduce the size of a jump table, but when you have a decision tree then it does not matter.... unless the size of immediate parameters would have affected code size. In the example code however, all constants fit in an `imm8` parameter to `cmp`.
-
All the values are divisible by 8, so it could do it like this: cmp eax,40 ja <return 0> test eax,7 jnz <return 0> jmp JumpTable[rax]
-
I remember having implemented similar things in JavaScript (by generating code), for immutable Maps and Sets - no significant performance gain in modern engines. For regular expressions of complex unicode ranges, the speedup was around 2x!
-
Why the indirection? - why not have the jump table reference f0..fX directly rather than jumping to a jump?
-
What a shame for clang and gcc! They still don't implement perfect hashes for large sparse switch tables. I did that recently for my rcc C compiler, and it was just a single day of work. Esp. beneficial for unicode work. The LLVM patch was rejected a decade ago. Gcc has several unicode patches sitting in branches, which would also need that
-
In order to peak into hardware speculation/BTB, having a look atswitch lowering seems a good way. Big switches will go into serious convolution to please that hardware since by definition this is a source of a lot of branch mispredicitions.
-
> The switch in sparse_8 could be simplified by dividing x by eight before the jump. Interestingly, gcc doesn't find this simplification.It could not because that would ensure that 7 values for each case would be handled by function calls instead of the default case - 0/8 is 0, but 3/8 is also 0