RFR 8203628: Optimize (masked) byte memory comparisons on x86

Aleksey Shipilev shade at redhat.com
Tue May 22 15:53:28 UTC 2018

On 05/22/2018 05:45 PM, John Rose wrote:
> On May 22, 2018, at 8:10 AM, Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>> wrote:
>> We have found this during Shenandoah performance work. There, the GC barrier fastpath checks the
>> thread-local byte field to see if barriers are enabled. It follows different shapes, e.g.:
>>  Set cr (CmpI (LoadB mem) imm))
>>  Set cr (CmpI (LoadUB mem) imm))
>>  Set cr (CmpI (AndI (LoadUB mem) imm) zero))
> Nicely done.  You covered both B and UB evenly.
> Just to verify:  There are already similar patterns for int32 and int64, right?

int32 seems to already have the matchers, e.g:

 instruct testI_reg_imm(rFlagsReg cr, rRegI src, immI con, immI0 zero) %{
   match(Set cr (CmpI (AndI src con) zero));

int64 does not look doable, because x86_64 does not let you use imm64 in test/cmp.

> And I have to ask, "what about" int16?  Do we care?  Probably not.

I prefer to ignore int16 for a time being. The current patch is almost straight-forward port from
current Shenandoah tree, and we are pretty sure it works reliably.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180522/1ea58589/signature.asc>

More information about the hotspot-compiler-dev mailing list