RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v6]

[Emanuel Peter]

On Fri, 20 Dec 2024 16:08:51 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 135:
>> 
>>> 133:     @IR(applyIf = {"SuperWordReductions", "true"},
>>> 134:         applyIfCPUFeatureOr = { "avx512", "true" },
>>> 135:         counts = {IRNode.MIN_REDUCTION_V, " > 0"})
>> 
>>> @eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further.
>> 
>> Hi @galderz , may I ask if these long-reduction cases can't work even with `sve`? It might be related with the limitation [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566). Some `sve` machines have only 128 bits.
>
> That's right. Neoverse V2 is 4 pipes of 128 bits, V1 is 2 pipes of 256 bits.
> That comment is "interesting". Maybe it should be tunable by the back end. Given that Neoverse V2 can issue 4 SVE operations per clock cycle, it might still be a win.
> 
> Galder, how about you disable that line and give it another try?

FYI: I'm working on removing the line [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566).

The issue is that on some platforms 2-element vectors are somehow really slower, and we need a cost-model to give us a better heuristic, rather than the hard "no". See my draft https://github.com/openjdk/jdk/pull/20964.

But yes: why don't you remove the line, and see if that makes it work. If so, then don't worry about this case for now, and maybe leave a comment in the test. We can then fix that later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1901576209