[llvm] Fix O(n^2) complexity in SliceUpIllegalIntegerPHI (PR #175468)

[Nikita Popov via llvm-commits]

https://github.com/nikic commented:

This does fix the problem, but I'd like to suggest an alternative: There is really no reason why this check should be expensive in the first place. Checking whether a block has an insertion point is really just "is the terminator catchswitch" (or maybe phrased more generically, "is the terminator an EH pad"), which is a cheap O(1) operation.

The only reason this ends up expensive here is that *finding* the insertion point (if it exists) requires scanning through all the phi nodes in the block. But just checking if there is one is cheap.

What I'd suggest doing is add a method BasicBlock::hasInsertionPt() and then use it here (can then keep the code in the original position). Then we can also update other occurrences of this pattern like these:
https://github.com/llvm/llvm-project/blob/a5fa2464356ced456e93ac1033e7460355d4eeaf/llvm/lib/Transforms/InstCombine/InstCombinePHI.cpp#L275
https://github.com/llvm/llvm-project/blob/a5fa2464356ced456e93ac1033e7460355d4eeaf/llvm/lib/Transforms/InstCombine/InstCombinePHI.cpp#L1455
https://github.com/llvm/llvm-project/blob/a5fa2464356ced456e93ac1033e7460355d4eeaf/llvm/lib/Transforms/Scalar/SROA.cpp#L1385
I haven't checked if any of those could have compile-time scalability issues, but better safe than sorry.

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