RFR(S) 8029302: Performance regression in Math.pow intrinsic

[Christian Thalinger]

On Apr 17, 2014, at 3:21 PM, David Chase <david.r.chase at oracle.com> wrote:

> You are right, what was I thinking?
> Does the intrinsic jump directly on Math.pow, or on some internal method that would make this an easy library fix?

Look at my last comment in the bug; we intrinsify Math.pow directly.  So we would need to introduce another method we intrinsify so the Java code stays.

> 
> David
> 
> On 2014-04-17, at 7:34 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> I’ve said this before (see bug report) and I say it again (last time, I promise):  yes, it is a performance regression in the C2 compiler but a MUCH better place to “fix" this would be in the library.  Cover the common and special cases there and only use the intrinsic for the uncommon cases.
>> 
>> On Apr 17, 2014, at 7:21 AM, David Chase <david.r.chase at oracle.com> wrote:
>> 
>>> As long as we are doing this as a constant-driven transform in the compiler,
>>> it might not hurt to also consider the case of x**3.  Cubes are common enough.
>>> 
>>> David
>>> 
>>> 
>>> On 2014-04-17, at 11:45 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>>> Niclas,
>>>> 
>>>> Looking on __ieee754_pow() in sharedRuntimeTrans.cpp and it has other simple cases:
>>>> 
>>>> x**0 = 1
>>>> x**1 = x
>>>> x**-1  = 1/x
>>>> x**0.5 = sqrt(x)
>>>> 
>>>> It would be nice to know which are frequently used and implement them too.
>>>> 
>>>> Also there is check for NaN before all this cases except x**0 = 1:
>>>> 
>>>> /* +-NaN return x+y */
>>>> 
>>>> You need to test that new C2 code produces the same results for NaN values.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>> 
>> 
>