8154867: PPC64: Better byte behavior
Doerr, Martin
martin.doerr at sap.com
Fri Apr 22 14:48:40 UTC 2016
Hi Coleen,
thanks for taking a look. Unfortunately, I've seen your email a little too late.
I agree with that btos/ztos/stos/ctos are unused for the return entry and should better get removed. So we could do a cleanup change.
I think the removal of those entry points makes sense which is what you have proposed:
https://bugs.openjdk.java.net/browse/JDK-8139788
Maybe we will be able to do some more PPC cleanup.
Best regards,
Martin
-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore
Sent: Freitag, 22. April 2016 15:12
To: hotspot-runtime-dev at openjdk.java.net
Subject: Re: 8154867: PPC64: Better byte behavior
Hi Martin,
http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/src/cpu/ppc/vm/templateTable_ppc_64.cpp.udiff.html
This change looks good except the code in ireturn looks strange because
state is never btos/ztos/stos/ctos. OR if it was btos,stos and ctos and
you're trying to return a boolean, there would have to be additional
narrowing for those cases too. It think it would be more accurate to
have the small int tos states above itos in your switch statement.
The only reason we added ztos was to make the backports easier for these
bugs. I think these unused tos optimization cases should be removed.
Do you agree?
https://bugs.openjdk.java.net/browse/JDK-8139788
Also, I guess it doesn't matter for ppc, but the April cpu code is in
http://hg.openjdk.java.net/jdk9/hs and I was going to push the zero
change from Severin there. Should you make these changes for that
repository instead?
thanks,
Coleen
On 4/22/16 4:55 AM, Doerr, Martin wrote:
> Hi,
>
> the PPC64 part of "Better byte behavior" (8148487) was done in jdk8u but is also needed in 9.
>
> Here's the port for 9/dev:
> http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/
>
> Please review.
>
> Best regards,
> Martin
>
More information about the hotspot-runtime-dev
mailing list