One of the scenarios mentioned in JDK-8351409 affects int min/max loops:

Given a loop with a int min/max reduction pattern with one side of branch taken near 100% of time, when Supeword finds the pattern not profitable, then HotSpot will use scalar instructions (cmov) and performance will regress.

Example java code:
```
import java.util.Random;

public class TestIntMaxEmanuel {
  private static Random RANDOM = new Random();

  public static void main(String[] args) {
    int[] a = new int[64 * 1024];
    for (int i = 0; i < a.length; i++) {
      a[i] = RANDOM.nextInt();
    }


    {
      System.out.println("Warmup");
      for (int i = 0; i < 10_000; i++) { test1(a); }
      System.out.println("Run");
      long t0 = System.nanoTime();
      for (int i = 0; i < 10_000; i++) { test1(a); }
      long t1 = System.nanoTime();
      System.out.println("Time: " + (t1 - t0));
    }

    {
      System.out.println("Warmup");
      for (int i = 0; i < 10_000; i++) { test2(a); }
      System.out.println("Run");
      long t0 = System.nanoTime();
      for (int i = 0; i < 10_000; i++) { test2(a); }
      long t1 = System.nanoTime();
      System.out.println("Time: " + (t1 - t0));
    }
  }

  public static int test1(int[] a) {
    int x = Integer.MIN_VALUE;
    for (int i = 0; i < a.length; i++) {
      x = Math.max(x, a[i]);
    }
    return x;
  }

  public static int test2(int[] a) {
    int x = Integer.MIN_VALUE;
    for (int i = 0; i < a.length; i++) {
      x = (x >= a[i]) ? x : a[i];
    }
    return x;
  }
}
```

Running:
```
$ java -XX:CompileCommand=compileonly,TestIntMaxEmanuel::test* -XX:CompileCommand=printcompilation,TestIntMaxEmanuel::test* TestIntMaxEmanuel.java
CompileCommand: compileonly TestIntMaxEmanuel.test* bool compileonly = true
CompileCommand: PrintCompilation TestIntMaxEmanuel.test* bool PrintCompilation = true
Warmup
3774 93 % 3 TestIntMaxEmanuel::test1 @ 5 (27 bytes)
3775 94 3 TestIntMaxEmanuel::test1 (27 bytes)
3776 95 % 4 TestIntMaxEmanuel::test1 @ 5 (27 bytes)
3782 96 4 TestIntMaxEmanuel::test1 (27 bytes)
Run
Time: 699 568 502
Warmup
5193 101 % 3 TestIntMaxEmanuel::test2 @ 5 (34 bytes)
5193 102 3 TestIntMaxEmanuel::test2 (34 bytes)
5194 103 % 4 TestIntMaxEmanuel::test2 @ 5 (34 bytes)
5198 104 4 TestIntMaxEmanuel::test2 (34 bytes)
Run
Time: 243 859 789
```

Tracing the auto vectorizer we observe that `test1` was not vectorized because it's not profitable:

```
WARNING: Removed pack: not profitable:
    0: 577 MaxI === _ 602 578 [[ 574 ]] !orig=519,448,199,175 !jvms: TestIntMaxEmanuel::test1 @ bci:15 (line 37)
    1: 574 MaxI === _ 577 575 [[ 567 ]] !orig=516,199,175 !jvms: TestIntMaxEmanuel::test1 @ bci:15 (line 37)
    2: 567 MaxI === _ 574 568 [[ 564 ]] !orig=448,199,175 !jvms: TestIntMaxEmanuel::test1 @ bci:15 (line 37)
    3: 564 MaxI === _ 567 565 [[ 519 ]] !orig=199,175 !jvms: TestIntMaxEmanuel::test1 @ bci:15 (line 37)
    4: 519 MaxI === _ 564 520 [[ 516 ]] !orig=448,199,175 !jvms: TestIntMaxEmanuel::test1 @ bci:15 (line 37)
    5: 516 MaxI === _ 519 517 [[ 448 ]] !orig=199,175 !jvms: TestIntMaxEmanuel::test1 @ bci:15 (line 37)
    6: 448 MaxI === _ 516 449 [[ 199 ]] !orig=199,175 !jvms: TestIntMaxEmanuel::test1 @ bci:15 (line 37)
    7: 199 MaxI === _ 448 200 [[ 602 357 252 ]] !orig=175 !jvms: TestIntMaxEmanuel::test1 @ bci:15 (line 37)

After Superword::filter_packs_for_profitable

PackSet::print: 0 packs

SuperWord::transform_loop failed: SuperWord::SLP_extract did not vectorize
```

`test2` is not vectorized because it contains control flow.

The assembly for `test1` looks like this:

```
  0x00007f3c7cad9e37: cmpl (%rsp), %eax
  0x00007f3c7cad9e3a: movl (%rsp), %r11d
  0x00007f3c7cad9e3e: cmovll %r11d, %eax ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestIntMaxEmanuel::test1@15 (line 37)
```

And for `test2`:

```
  0x00007f3c7cadb300: cmpl %r11d, %eax
  0x00007f3c7cadb303: jl 0x7f3c7cadb367 ;*istore_1 {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestIntMaxEmanuel::test2@25 (line 45)
```

This issue can also be observed with the `MinMaxVector` benchmark added in JDK-8307513. The test scenarios above are represented by `intReductionSimpleMax`. To emulate `test2`, simply disable the `_max` intrinsic (-max below). The results are on an AVX-512 machine are:

```
Benchmark (probability) (range) (seed) (size) Mode Cnt -max +max Units
MinMaxVector.intReductionSimpleMax 100 N/A N/A 2048 thrpt 4 998.211 460.404 ops/ms (-53%)
```

Again we observe that `test2` equivalent is faster.

Please also note that testing int min has to be done with care, as explained in this [jmh-dev](https://mail.openjdk.org/pipermail/jmh-dev/2025-February/004094.html) mailing thread. One way to mitigate might be to use compiler threshold scaling, to make Math.min(II) be compiled later. This needs to be verified.

One important difference between int and long min/max is that the support for int vectorized min/max instructions are more widely available. So this regression should happen less often compared to long min/max.