[llvm] Optimization on predecessor count checks for FunctionPropertiesAnalysis (PR #198940)

[Iñaki V Arrechea via llvm-commits]

InakiVA wrote:

> It's unclear to me how this is an optimization. We're doing the exact same logic but no looking at the distance more often. I'm pretty sure `pred_size` and `hasNPredecessors` both end up being O(n) on the number of predecessors given the predecessor iterator is not random access. Did this come up on the flame graph?

https://github.com/llvm/llvm-project/blob/2b460b36bdb4ab8f239f5efc38ad83ffde9b1b35/llvm/include/llvm/ADT/STLExtras.h#L2607-L2612


It is not in O(n), it is in O(N), with N referring to the number specified in has**N**Items (same for hasNItemsOrMore). Size is O(n), with n being the amount of predecessors of the basic block which can be much more than the maximum we need, 3



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