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