[llvm] [TaiDup] Allow large number of predecessors/successors without phis. (PR #116072)

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 18 13:30:19 PST 2024


fhahn wrote:

> Are these inputs computed gotos or jump tables? If they are computed gotos, I think we can land #114990.
> 
> In fact, I don’t see any difference between computed gotos and jump tables—both can include or exclude many PHIs. To me, the only difference is that a jump table has one extra jump at the source level compared to a computed goto. So, I believe that when users use computed gotos, they expect longer compile times and larger code size.

Ah I missed the other PR, thanks! For this particular case, it is a computed GOTO, but there are other computed GOTOs, but completely removing the cutoff increases the # of instructions by 10%, without any gain.

In general, I think we should try to avoid cut-offs if there are cases we can handle with reasonable compile-times. I am not sure if completely ignoring the cutoff for computed GOTOs is the best way forward, as I don't see a fundamental difference between coming from jump tables or compute GOTOs.

Ideally we would address allow cases we can reasonably handle (e.g. because there are no phis to add) and/or by addressing the extra complexity for adding the additional edges to the CFG.

For the test-case from https://github.com/llvm/llvm-project/issues/106846 (http://www.jikos.cz/~mikulas/testcases/clang/computed-goto.c), tail folding is applied with the current patch as well, but only the inner level I think. I don't have a suitable X86 to test if it restores the original performance

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


More information about the llvm-commits mailing list