RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v3]
Emanuel Peter
epeter at openjdk.org
Tue Mar 12 16:56:19 UTC 2024
On Tue, 12 Mar 2024 16:51:27 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
>> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>>
>> - Merge branch 'master' into round-v-exhaustive-tests
>> - fix issue
>> - mv tests
>> - use IR framework to construct the random tests
>> - Initial commit
>
> test/hotspot/jtreg/compiler/vectorization/TestRoundVectorDoubleRandom.java line 124:
>
>> 122: bits = bits | (1 << 63);
>> 123: input[ei_idx*2+1] = Double.longBitsToDouble(bits);
>> 124: }
>
> Why do all this complicated stuff, and not just pick a random `long`, and convert it to double with `Double.longToDoubleBits`?
Does this ever generate things like `+0, -0, infty, NaN` etc?
> test/hotspot/jtreg/compiler/vectorization/TestRoundVectorDoubleRandom.java line 134:
>
>> 132: for (int sign = 0; sign < 2; sign++) {
>> 133: int idx = ei_idx * 2 + sign;
>> 134: if (res[idx] != Math.round(input[idx])) {
>
> Is it ok to use `Math.round` here? What if we compile it, and its computation is wrong in the compilation?
This direct comparison tells me that you are not testing `NaN`s...
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1521817370
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1521817764
More information about the hotspot-compiler-dev
mailing list