RFR: 8324655: Identify integer minimum and maximum patterns created with if statements [v3]

[Emanuel Peter]

On Tue, 27 Feb 2024 18:23:41 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> @jaskarth 
>>> I've designed this benchmark
>> 
>> Nice. Can you also post the generated assembly for Baseline/Patch?
>> I'm just worried that there is some method call, or something else that does not get cleanly inlined and could mess with the benchmark.
>
> @eme64 Sure, here is the assembly for the baseline: https://gist.github.com/jaskarth/1fe6f00a5b37fe3efb0dd6a2d24840e0
> And after: https://gist.github.com/jaskarth/99c56e2f081f996987b96d7e866aca6c
> 
> I must have missed this originally when evaluating the benchmark, but looking at the assembly it seems like the baseline JDK creates a `CMove` for that ternary already. I made a quick patch to disable where `PhaseIdealLoop::conditional_move` is called, and the performance still stays the same on the benchmark. I've also attached that assembly if it's of interest: https://gist.github.com/jaskarth/7b12b688f82a3b8e854785f1827b0c20

@jaskarth It seems we were aware of such issues a long time ago:
https://bugs.openjdk.org/browse/JDK-8039104: Don't use Math.min/max intrinsic on x86
So we may actually have use `if` for min/max instead of CMove, at least on some platforms.
But some platforms may have worse branch predictors, and then we should use CMove more often.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17574#issuecomment-1974762928