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

Jasmine Karthikeyan jkarthikeyan at openjdk.org
Thu Jan 25 19:02:35 UTC 2024


On Thu, 25 Jan 2024 18:15:21 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

> Hi all, I've created this patch which aims to convert common integer mininum and maximum patterns created using if statements into Min and Max nodes. These patterns are usually in the form of `a > b ? a : b` and similar, as well as patterns such as `if (a > b) b = a;`. While this transform doesn't generally improve code generation it's own, it simplifies control flow and creates new opportunities for vectorization.
> 
> I've created a benchmark for the PR, and I've attached some data from my (Zen 3) machine:
> 
>                                                 Baseline                     Patch            Improvement
> Benchmark                   Mode   Cnt  Score      Error  Units    Score       Error  Units
> IfMinMax.testReductionInt   avgt   15  500.307 ±  16.687  ns/op    509.383 ±  32.645  ns/op   (no change)*
> IfMinMax.testReductionLong  avgt   15  493.184 ±  17.596  ns/op    513.587 ±  28.339  ns/op   (no change)*
> IfMinMax.testSingleInt      avgt   15    3.588 ±   0.540  ns/op      2.965 ±   1.380  ns/op   (no change)
> IfMinMax.testSingleLong     avgt   15    3.673 ±   0.128  ns/op      3.506 ±   0.590  ns/op   (no change)
> IfMinMax.testVectorInt      avgt   15  340.425 ±  13.123  ns/op     59.689 ±   7.509  ns/op   + 5.7x
> IfMinMax.testVectorLong     avgt   15  326.420 ±  15.554  ns/op    117.190 ±   5.622  ns/op   + 2.8x
> 
> 
> * After writing this benchmark I discovered that the compiler doesn't seem to create some simple min/max reductions, even when using Math.min/max() directly. Is this known or should I create a followup RFE for this?
> 
> The patch passes tier 1-3 testing on linux x64. Reviews or comments would be appreciated!

Ah true, I hadn't considered that- do you think it makes sense to only do the transform if the if statement isn't highly predictable? I'm not sure what an appropriate threshold value would be, but it seems `PhaseIdealLoop::conditional_move` doesn't make cmoves if the percentage is < 1% or > 99% (disregarding the different handling for loops.) And it seems the other transforms in this group suffer from this as well 😄

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

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


More information about the hotspot-compiler-dev mailing list