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

[Vladimir Kozlov]

On 4/17/14 11:04 PM, Christian Thalinger wrote:
>
> 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.

We asked about this and the answer was: no, changes should be in VM.
I updated the bug report.

thanks,
Vladimir

>
>>
>> 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
>>>>
>>>
>>
>