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