[llvm] [CloneFunction] Optimize PHI incoming value removal using reverse iteration (NFC) (PR #171955)

[via llvm-commits]

int-zjt wrote:

> I don't think you need to use addIncoming, the current code structure with setIncoming should work, as it only sets the current element. But overall, I agree that mixing modification and removal in removeIncomingValueIf() is a bit iffy. I'm fine with your change.

Sorry, I mixed up the context with another patch regarding the `addIncoming` logic. However, my concern remains similar for this location. If I use `removeIncomingValueIf`, I would need to perform the updates inside the predicate:

```cpp
PN->removeIncomingValueIf([&](unsigned i) {
    // ... checks ...
    // Side effects inside the predicate:
    PN->setIncomingValue(pred, InVal);
    PN->setIncomingBlock(pred, MappedBlock);
    return true; // or false based on logic
});
```

Having `setIncomingValue` and `setIncomingBlock` inside a removal predicate still feels like introducing significant side effects into what should be a check. Do you think this pattern is acceptable here?

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