RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]

[Andrew Haley]

On Tue, 20 Apr 2021 22:39:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > This may be unsafe. AFAIK there is no guarantee about the monotonicity of `Math.pow(x, y)` as y moves from `Math.pow(x, nextAfter​(0.5, -1)` to `Math.pow(x, 0.5)` to `Math.pow(x, nextAfter​(0.5, 1)` for all x. Did anyone look?
> 
> Thanks @theRealAph for your review.
> 
> What did you mean by `Math.pow(x, nextAfter​(0.5, -1)` and `Math.pow(x, nextAfter​(0.5, 1)` ?

>From the spec, "errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation."

nextAfter "Returns the floating-point number adjacent to the first argument in the direction of the second argument."

Using sqrt() rather than pow() for pow(x,0.5) will return different results for some arguments. For this optimization you're proposing to be safe, you need to prove that in such cases the "Results must be semi-monotonic" requirement is still satisfied. 

There may exist values of pow(x,0.5) where, if we substitute sqrt() this requirement is not met. I don't immediately know how to prove this does not happen. I think that to do so would require careful analysis.

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

PR: https://git.openjdk.java.net/jdk/pull/3404