GCC: is there an optimization for the switch (...)?

[lz77]

In Delphi 7 such a trick is possible with the calculation of the jump address in the case statement. For example, there is case statement by prefix = 0,1,2,3 when LZ decompressing (but it breaks optimization):

var
 cm0: array[0..3] of dword;
...

asm
mov dword [cm0],offset m0
mov dword [cm0+4],offset m1
mov dword [cm0+8],offset m2
mov dword [cm0+12],offset m3
end;

<Decompressing loop starts>

asm
mov eax,prefix
jmp offset cm0+eax*4
end;


m0:    offs:=...; goto 1000;
m1:    offs:=...; goto 1000;
m2:    offs:=...; goto 1000;
m3:    offs:=...;

1000:

Is it possible in C to calculate the addresses of the labels and make such a jump? Or does the translator do it itself?

[Stefan Atev]

I think most modern compilers can do that optimization; if you're interested to investigate, I can't recommend https://godbolt.org/ highly enough.

Here is an dumb example with a switch statement: https://godbolt.org/z/hK634x

Notice the indirect jump straight into the case: jmp [QWORDPTR.L4[0+rdi*8]]

[Shelwien]

Its possible, but its a gcc extension: https://gcc.gnu.org/onlinedocs/gcc/L...as-Values.html
clang/gcc/IntelC do support it: https://godbolt.org/z/s4EboW
VS only via inline asm: https://stackoverflow.com/questions/...of-labels-msvc

[lz77]

In my decompressor GCC does not use jmp label to optimize switch, only conditional jmps. I tried to use goto *labels[pref], but it decreases speed on 40%...

Now my program decompresses enwik8 in 0.328 sec. vs. 0.234 sec. by zstd (40% worse in decompression time, 1.5% better in ratio). I will do some optimizations in algorithm, then will port it from C to asm to see its power. After that I will do the same with my compressor (Delphi 7 -> C -> asm).

[Stefan Atev]

Whether GCC will use a jump table or not depends on many details, including the exact arch you compile for. Jump table might be preferred on older Intel microarchs, but not on newer ones, etc. There are three ways to control things, and you can experiment with them if you really want (full list at https://gcc.gnu.org/onlinedocs/gcc/O...e-Options.html) I think the spacing (gaps) in case statements and the presence of default: cases can also affect the decision to use the optimization. I really wish more compilers had #pragma statements to locally tweak such decisions, but they can also be fragile optimizations. I remember trying to get msvc to produce a conditional move at one point, and it worked great for Penryn, but later on, for Haswell, on the same tests was worse than eating a branch.

Adding --param case-values-threshold=10 to the example I linked above disabled the jump table;

You can pass these to gcc with --param name=value

case-values-threshold The smallest number of different values for which it is best to use a jump-table instead of a tree of conditional branches. If the value is 0, use the default for the machine.

jump-table-max-growth-ratio-for-size The maximum code size growth ratio when expanding into a jump table (in percent). The parameter is used when optimizing for size.

jump-table-max-growth-ratio-for-speed The maximum code size growth ratio when expanding into a jump table (in percent). The parameter is used when optimizing for speed.

[lz77]

I've added
--param jump-table-max-growth-ratio-for-speed=100
​to command line, but saw the message:
cc1.exe: error: invalid --param name 'jump-table-max-growth-ratio-for-speed'

[e8c]

... , but saw the message:
cc1.exe: error: invalid --param name 'jump-table-max-growth-ratio-for-speed'

​
In my opinion, this is a great reason to stop doing such an unnatural thing as using GCC on Windows.

UPD: even if on Linux there is the same message

[Shelwien]

Try it like this: "g++ --param=jump-table-max-growth-ratio-for-speed=10 1.cpp"
Also see the bottom of https://gcc.gnu.org/onlinedocs/gcc/O...e-Options.html - there may be other useful parameters.