RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v9]

[Hamlin Li]

On Fri, 5 Apr 2024 10:12:29 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> There's no need for randomness or arrays or special values in the 32-bit case. You can, and should, test the entire 32-bit range in a few lines of code by using floatBitsToInt.
>> 
>> In previous discussion, there are several reasons why it's implemented in this way:
>> 1. test the whole range of 32 bits is slow, and even slow for a 64 ranges double.
>> 2. if it's too slow, then it's not feasible to make it an automatic test.
>> these are expected by @eme64.
>> 
>>> You can make the test much faster by copy-and-pasting the library code for Math.round(float) and letting the JIT compile it.
>> 
>> Previously, I had [this question](https://github.com/openjdk/jdk/pull/17753#issuecomment-1992519401), but from the point view of correctness of the golden value.
>> I think you make another point to change from @DontCompile to copying library java code. Thanks!
>> I will do it.
>
>> > There's no need for randomness or arrays or special values in the 32-bit case. You can, and should, test the entire 32-bit range in a few lines of code by using floatBitsToInt.
>> 
>> In previous discussion, there are several reasons why it's implemented in this way:
>> 
>> 1. test the whole range of 32 bits is slow, and even slow for a 64 ranges double.
> 
> I guess we could try it for 32 bit floats. But it would take a while. If we can make sure it does not take much more than one minute, we can do that. But of course 64 bit doubles would be infeasible.

As I remember, that's not the case in my local environment, i.e. it will take longer time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1553352302