RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9
richard.reingruber at sap.com
Fri Dec 14 08:44:45 PST 2012
thanks for looking at the patch.
> convI2L_reg_zex doesn't use the mask
Yes, in convI2L_reg_zex the mask is only there for matching the zero-extension pattern in the ideal graph. It's not needed as real immediate value.
With the expand it's not needed at all (could be set to 0xdeadbeef), but it doesn't hurt either. There is no overhead I would be aware of. Especially not at runtime.
> so would shrI_reg_imm5(dst, src, 0) or shrI_reg_reg(dst, src, R_G0) work
> just as well?
Probably, I thought the purpose (zero-extension) would be clearer when using convI2L_reg_zex.
From: Dean Long [mailto:dean.long at oracle.com]
Sent: Donnerstag, 13. Dezember 2012 19:44
To: Reingruber, Richard
Cc: hotspot compiler (hotspot-compiler-dev at openjdk.java.net)
Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9
convI2L_reg_zex doesn't use the mask, so would shrI_reg_imm5(dst, src, 0) or
shrI_reg_reg(dst, src, R_G0) work just as well?
On 12/13/2012 9:09 AM, Reingruber, Richard wrote:
> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9.
> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount().
> I have prepared a small webrev with the suggested fix and a regression test:
> Could you please review the patch and create a bug id? Thanks!
> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :)
More information about the hotspot-compiler-dev