[llvm] Default aarch64-min-jump-table-entries to 9 (PR #98391)

[David Green via llvm-commits]

davemgreen wrote:

> > What do you mean by "weren't significantly better", and do you have a reason to change this to 9?
> 
> Based on the comment here: [#71166 (comment)](https://github.com/llvm/llvm-project/pull/71166#issuecomment-1810505765) and [#71166 (comment)](https://github.com/llvm/llvm-project/pull/71166#issuecomment-1819206582)
> 
> 13 is too large IMO, it results in codesize increase and it seems like #71166 was purely chosen for benchmarking purposes. Is there a way to find a better number here?
> 
> The number of branches is of the order of 2*(number of cases), it may appear fine for benchmarking purposes but i dont think this is a good idea to generate so many branches when jump table was sufficient.

I'm not particularly married to the current value. I'm not sure if there is a single optimal values, and the one we have is kind of odd, but if we are changing it then I would hope we had a better reason. We used to have a lower value, GCC has always used a values closer to what we have now. The real answer can likely depend on many issues like the predictability of each of the branches or the relative capability of the branch predictor in the cpu.

When I try this patch on the llvm test suite + 3 versions of spec, the geomean performance is 0.1% worse. The codesize doesn't change (at -O3, it might be different at other opt levels). Those results are ran very quickly though, so might be more noisy than we would like, and this patch in general will lead to changes that are often noisy due to the nature of branches being differently aligned. If we ran it a week earlier or a week later the performance might be totally different for it.

https://github.com/llvm/llvm-project/pull/98391