What a shame for clang and gcc! They still don&#x27;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

&gt; The switch in sparse_8 could be simplified by dividing x by eight before the jump. Interestingly, gcc doesn&#x27;t find this simplification.<p>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&#x2F;8 is 0, but 3&#x2F;8 is also 0

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?

This one was interesting, especially its name :)

In order to peak into hardware speculation&#x2F;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.

HN

Switch Lowering in GCC

Comments (22)