RFR: 8302673: [SuperWord] MaxReduction and MinReduction should vectorize for int

Emanuel Peter epeter at openjdk.org
Wed May 17 10:59:46 UTC 2023


On Wed, 17 May 2023 10:54:43 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> The canonicalization of MinI/MaxI chains into right-spline graphs within `MinINode/MaxINode::Ideal()` inhibits the vectorization of reductions of these nodes. This changeset reworks `MinINode/MaxINode::Ideal()` to perform the same algebraic optimizations without the need for canonicalization, re-enabling auto-vectorization of MinI/MaxI reductions. This is achieved by handling all four permutations of the targeted Ideal subgraph induced by the commutativity of MinI/MaxI directly. The algorithm (for the MaxI case, the MinI case is analogous) tries to apply two Ideal graph rewrites in the following order, where `c0` and `c1` are constants and `MAX` is a compile-time operation:
>> 1. `max(x + c0, max(x + c1, z))` (or a permutation of it) to `max(x + MAX(c0, c1), z)`.
>> 2. `max(x + c0, x + c1)` (or a permutation of it) to `x + MAX(c0, c1)`.
>> 
>> Here is an example of the four permutations handled in step 1 with `x = RShiftI`, `c0 = 100` or `150`, `c1 = 150` or `100`, and `z = ConI (#int:200)`:
>> 
>> ![two-level-idealization](https://github.com/openjdk/jdk/assets/8792647/bf60a2c3-39cd-4f0d-965d-c711723e374c)
>> 
>> Here is an example of the two permutations handled in step 2 with `x = RShiftI`, `c0 = 10` or `11`, and `c1 = 11` or `10`:
>> 
>> ![one-level-idealization](https://github.com/openjdk/jdk/assets/8792647/0a1fe85b-3f30-46bc-8817-d90b3eff946c)
>> 
>> The changeset implements `MinINode/MaxINode::Ideal()` in a common method `MaxNode::IdealI()`, since the algorithm is symmetric for both node types. The changeset also extends the existing MinI/MaxI Idealization tests with positive tests for all targeted permutations and negative tests, and adds a new test (contributed by @jbhateja) to assert that MinI/MaxI reductions are vectorized.
>> 
>> #### Testing
>> 
>> ##### Functionality
>> 
>> - tier1-5, stress test, fuzzing (windows-x64, linux-x64, linux-aarch64, macosx-x64, macosx-aarch64; release and debug mode).
>> 
>> ##### Performance
>> 
>> - Tested performance on a set of standard benchmark suites (DaCapo, SPECjbb2015, SPECjvm2008). No significant change was observed.
>
> test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Int.java line 82:
> 
>> 80:         for (int i = 0; i < a.length; i++) {
>> 81:             a[i] = -i;
>> 82:             b[i] = i;
> 
> That means that `a[i] * b[i] == -i*i`, and get increasingly smaller. I think it would be better if this was a bit more random, and not biased to the maximum always being at the beginning and the minimum at the end.

Plus, we should try to cover the whole int range, or at least as much as possible.
One solution: just pick two random ints, and then add/subtract them before min/max.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13924#discussion_r1196312184


More information about the hotspot-compiler-dev mailing list