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

[David Chase]

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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140417/bfe5371d/signature.asc>