[llvm] Add a pass to convert jump tables to switches. (PR #77709)

[David Li via llvm-commits]

david-xl wrote:

> Thanks. My high level concern with this patch is that profitability is quite unclear. There are two general cases:
> 
> 1. We convert the jump table, but the resulting calls do not get inlined. The end result is that we go from a load and indirect branch to a switch, which will probably get lowered in some less efficient way (e.g. a jump table to a direct call). See https://github.com/dtcxzyw/llvm-opt-benchmark/pull/194/files#diff-eec1b5b777c9e8fcf7801b8c80004f1055ae1c04951b49a38fa52a06bd15f760 for an example where this happens. Right now, I'm not sure if we are able to undo this transform at all -- I initially thought that normal switch to jump table conversion will handle it, but thinking about it again now, I don't think it supports this pattern involving calls.
> 2. We convert the jump table and the calls do get inlined. This may or may not be beneficial. The case you probably have in mind here is the case where the calls are actually small functions and inlining them results in overall simplification. However, it can also happen that they are large functions that will not receive any substantial benefits from inlining. In that case, inlining is them into one large function with a switch is probably worse than the existing jump table.
> 
> Overall, I'm unsure whether this is a good idea, at least when done unconditionally.

Those are all valid concerns. It seems it needs some cost model for profitability analysis (also depend on it is optimize for size or speed).  Things to consider when optimize for speed:

1) with profile feedback, this optimization should probably be turned off:
   a) if there is a dominating case, the existing indirect call promotion will peel the case out and make it direct calls
   b) if the jump targets are equally likely, convert them into switch will likely hurt performance as Niki mentioned: when switch is not properly lowered, it does not help code layout, nor branch predictor.

2) without profile feedback, it is probably better to check function body  availability and consult Inliner to see if callee is profitable to be inlined (this API can be useful for other clients).

For now, if looks fine to me to go in if

a) have a flag that is off by default
b) the pass is on with Os/Oz but without profile (or cold function)
c) check target function definition and they need to be smaller than threshold.

nikic@, WDTY?

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