Hacker News Reader

Comment by tsukikage | Hacker News Reader

Why the indirection? - why not have the jump table reference f0..fX directly rather than jumping to a jump?

That optimisation is simply missing.

Each `jmp` to f0..fX is an optimisation of a `call` and a `ret`, and probably done in a separate pass after the switch-case code has already been expanded.

The `mov edi, esi` at the top of the function is also an optimisation, most likely done during the register allocation pass. This was only possible because all functions take the same value in the same register. Otherwise, there would probably have been also a `mov` before each of the calls.

gcc unfortunately cannot do this (and also not the related optimization of using word/byte offsets for the jump table, which LLVM can do) because it only has approximate estimation of code size. If it got the code size wrong it would be a mis-compilation. This is related to it not using an integrated assembler.

Why does it need to know code size to put function addresses in the jump table?

Not necessarily function addresses but jump table targets. Those can be in the middle of a subroutine. If you don't know the addresses then you need to keep them symbolic and if they're symbolic they are subject to change, for instance they could end up 'on the bubble' of fitting in a small offset or they might just spill over into a larger one. And that would change the data type of the jump table. If you have a built in binary code generator then will know the addresses exactly at compile time.

But the jump table uses full 64-bit absolute addresses. It can fit anything.

Reply on news.ycombinator.com