This is an attempt of fixing PR35807.
Due to the non-standard definition of dominance in LLVM, where uses in unreachable blocks are dominated by anything, you can have, in an unreachable block
%patatino = OP1 %patatino, CONSTANT
When SimplifyInstruction receives a PHI where an incoming value is of the aforementioned form, in some cases, loops indefinitely (see the stack trace in the PR). I, pretty honestly, tried to figure out what was wrong in ValueTracking and it seems cause a loop, but I wasn't really able to get to the bottom of it as SimplifyInstruction/ValueTracking recently became a big mess.
What I propose here instead is keeping track of the incoming values from unreachable blocks, and replacing them with undef. This fixes this case, and it seems to be good regardless (even if we can't prove that the value is constant, as it's coming from an unreachable block, we can ignore it).
OTOH, I don't want to paper over the issue, so if somebody feels brave enough to take a look, I'll abandon this (although it might go in for the reasons explained above).
I experimented using a domtree to query reachability rather than RPOT, but it doesn't seem to make a difference for compile time even for large test cases(where we spend a decent fraction of time in CVP).
This call invalidates the set of reachable blocks.