RFR: Fix, improve and refactor matrix barrier on AAarch64
Andrew Haley
aph at redhat.com
Mon Sep 25 10:01:44 UTC 2017
On 14/09/17 16:20, Aleksey Shipilev wrote:
> On 09/14/2017 05:19 PM, Roman Kennke wrote:
>>>
>>>> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/
>>> Good, except for rscratch1 change.
>>
>> Ok, I made it a compromise: kept the method signature the same (i.e. 2 tmp args), and declare tmp3
>> at the beginning of the code block to be rscratch1.
>>
>> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.02/
This is confusing code. Giving rscratch1 a name like "tmp3" doesn't
help anyone, and it adds risk because many macros implicitly clobber
rscratch1. Something like this (untested) is clearer:
// Compute matrix index
mov(rscratch1, matrix->stride_jint());
// Address is _matrix[to * stride + from]
madd(tmp, tmp, rscratch1, tmp2);
mov(rscratch1, matrix->magic_offset());
Address loc(tmp, rscratch1);
ldrb(tmp2, loc);
cbnzw(tmp2, done);
mov(tmp2, 1);
strb(tmp2, loc);
bind(done);
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the shenandoah-dev
mailing list