[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