[llvm] [ValueTracking] Handle recursive select/PHI in ComputeKnownBits (PR #114689)

[via llvm-commits]

goldsteinn wrote:

> > > > > I don't fully understand the recursion limit handling here, both in the old and the new code. Why is it safe to use the full depth for the select case? Can't you have multiple phi incoming values that are all selects and perform a full-depth walk on all of them?
> > > > 
> > > > 
> > > > I think that the pathological case is a recursive phi is `Num_Phi_Nodes^(MaxDepth - CurDepth)`, if we know we aren't hitting a case that doesn't scale exponentially with `Depth` its seems reasonable enough. Also it seems highly unlikely even in a PHI with a thousand arms to have ALL of them be select-referential selects.
> > > 
> > > 
> > > But doesn't that scale potentially exponentially? Especially if you take into account the fact that the other select operand may in fact also be based on the phi (just take something like `c ? phi + 1 : phi`), so we get the usual recursive fan-out problem, just with a select interleaved in between.
> > 
> > 
> > Yes, you could still construct an input that would cause serious perf regressions here. Although based on available data this seems more of a theoretical problem than a practical one. Should we sacrifice practical analysis quality for a theoretical compile time regression?
> 
> Yes, we should always protect against pathological cases, even if we have not encountered them in practice yet.

Okay, will update

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