[llvm] [LV] Fix handleFirstArgMinOrMax to use 0 as identity element for UMax/SMax (PR #192054)

[Akash Agrawal via llvm-commits]

akashagrwl wrote:

> > PoisonValue, which can result in undefined behavior if the strict predicate is never met
> 
> Could you provide more details about what kind of UB this would expose? The poison should never leak, as the final select should propagate the original start value

You're right that in the specific case where the condition is never true, the final select would propagate the original start value. However, the issue is more subtle: the guard `AlwaysFalse = icmp eq MinOrMaxResult, MinOrMaxPhiR->getStartValue()` is incorrect (see the other comment). Additionally, using PoisonValue as the initial value for a UMax/SMax reduction is semantically problematic - while the poison may not leak in the current implementation, it creates fragile code that depends on specific optimization patterns. Using 0 (the identity element for UMax/SMax) is the correct approach and avoids these issues entirely.

We have confirmed this is causing wrong-code generation in a real-world signal processing benchmark (argmax with strict > predicate, returning 0 instead of the correct index). This PR fixes the issue


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