RFR: 8364305: Support AVX10 saturating floating point conversion instructions [v14]
Jatin Bhateja
jbhateja at openjdk.org
Sat Sep 13 08:40:27 UTC 2025
On Sat, 13 Sep 2025 01:21:12 GMT, Mohamed Issa <missa at openjdk.org> wrote:
>> Intel® AVX10 ISA [1] extensions added new saturating floating point conversion instructions which comply with definitions in section 5.8 of the 2019 IEEE-754 standard. They can compute floating point to integral type conversions while also handling special inputs such as NaN, +Infinity, and -Infinity.
>>
>> Without AVX10.2, the current approach starts by converting the floating point value(s) in the source register to the desired integral value(s) in the destination register. In the scalar case, the CVTTSS2SI (single precision) or CVTTSD2SI (double precision) instruction is used. In the vector case, the CVTTPS2DQ (single precision) or CVTTPD2DQ (double precision) is used. However, if the source contains a special value (NaN, -Infinity, +Infinity, <= Integer.MIN_VALUE, or >= Integer.MAX_VALUE), extra handling is required. The specific sequence of instructions involved depends on the source (single precision vs double precision), destination (long, integer, short, or byte), level of parallelization (scalar vs vector), and supported AVX extension type. Essentially though, the special values are mapped to values (NaN -> 0, -Infinity, <= Integer.MIN_VALUE -> Integer.MIN_VALUE, +Infinity, >= Integer.MAX_VALUE -> Integer.MAX_VALUE) in the integer range with the help of a few temporary regis
ters to store intermediate results.
>>
>> This change uses the new AVX10.2 scalar (VCVTTSS2SIS or VCVTTSD2SIS) and vector (VCVTTPS2QQS, VCVTTPS2DQS, VCVTTPD2QQS, and VCVTTPD2DQS) instructions on supported platforms to avoid the extra handling described above. Also, the JTREG tests listed below were used to verify correctness with `-XX:-UseSuperWord` / `-XX:+UseSuperWord` options to exercise both scalar and vector paths. The baseline build used is [OpenJDK v26-b11](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B11).
>>
>> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
>> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
>> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
>> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
>> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
>> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`...
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>
> Introduce scalar floating point conversion tests with IR rules
test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java line 70:
> 68: float_arr[i] = ran.nextFloat(floor_val, ceil_val);
> 69: double_arr[i] = ran.nextDouble(floor_val, ceil_val);
> 70: }
Please use Generators instead of direct initialization.
test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java line 89:
> 87: if (int_arr[i] != expected) {
> 88: throw new RuntimeException("Invalid result: int_arr[" + i + "] = " + int_arr[i] + " != " + expected);
> 89: }
Use Verify.checkEQ instead.
test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java line 109:
> 107: if (long_arr[i] != expected) {
> 108: throw new RuntimeException("Invalid result: long_arr[" + i + "] = " + long_arr[i] + " != " + expected);
> 109: }
Use Verify.checkEQ, checkout relevant code in https://github.com/openjdk/jdk/tree/master/test/hotspot/jtreg/compiler/lib and their usages
test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java line 122:
> 120: checkf2short();
> 121: }
> 122:
What is the reason behind additional level of abstraction when now manually inline this code.
test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java line 138:
> 136: applyIfCPUFeature = {"avx10_2", "false"})
> 137: @IR(counts = {IRNode.X86_SCONV_F2I_AVX10, "> 0"},
> 138: applyIfCPUFeature = {"avx10_2", "true"})
These IR rules apply to the CompilePhase.MATCHING
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26919#discussion_r2346076729
PR Review Comment: https://git.openjdk.org/jdk/pull/26919#discussion_r2346078144
PR Review Comment: https://git.openjdk.org/jdk/pull/26919#discussion_r2346080343
PR Review Comment: https://git.openjdk.org/jdk/pull/26919#discussion_r2346082356
PR Review Comment: https://git.openjdk.org/jdk/pull/26919#discussion_r2346097798
More information about the hotspot-compiler-dev
mailing list