search

eclipse / omr

Eclipse OMR™ Cross platform components for building reliable, high performance language runtimes
http://www.eclipse.org/omr
Other
945 stars 396 forks source link

Power code generator does not sign/zero-extend bshr and sushr opcodes #3535

Closed Leonardo2718 closed 5 years ago

Leonardo2718 commented 5 years ago

When GRA is disabled, code generators are required to spill arguments that come in registers and to reload them when an argument value is used.

Given the following trees:

(method return=Int16 args=[Int16, Int32] 
  (block 
    (ireturn 
      (su2i 
        (bshr
          (sload parm=0) 
          (iload parm=1)) ))))

the Power code generator generates the following code (GRA is disabled; 64-bit LE Power Linux machine):

1:  li      r2,32767
2:  rldicr  r2,r2,32,31
3:  oris    r2,r2,63376
4:  stdu    r1,-48(r1)
5:  stw     r3,32(r1)
6:  stw     r4,40(r1)
7:  lbz     r0,32(r1)
8:  lwz     r3,40(r1)
9:  sraw    r3,r0,r3
10: addi    r1,r1,48
11: blr

At line 7, the first argument is loaded as a byte into r0 and is zero-extended. At line 9, sraw does a word (32-bit) arithmetic right-shift of the value in r0. However, the value must first be sign-extended in order for the shift to correctly apply to the byte value.

Also, given the following trees:

(method return=Int16 args=[Int16, Int32] 
  (block 
    (ireturn 
      (su2i 
        (sushr 
          (sload parm=0)
          (iload parm=1)) ))))

the Power code generator generates:

1:  li      r2,32767
2:  rldicr  r2,r2,32,31
3:  oris    r2,r2,63376
4:  stdu    r1,-48(r1)
5:  stw     r3,32(r1)
6:  stw     r4,40(r1)
7:  lha     r0,32(r1)
8:  lwz     r3,40(r1)
9:  srw     r0,r0,r3
10: clrlwi  r3,r0,16
11: addi    r1,r1,48
12: blr

In this case, the first argument, a half-word, is loaded at line 7 and sign-extended. However, for the logical shift-right at line 9 to correctly apply to the 16-bit value, it must be zero-extended instead.

Finally, there is another issue, related to #3525, where sub-integer sized arguments are spilled to the stack as 32-bit words but are reloaded with a different bit width. The issue is not causing immediate problems because tests are only run on LE systems where narrowing conversions can be done without changing the base address of a value in memory.

Leonardo2718 commented 5 years ago

Like #3525, this issue was discovered in #3499 by changing the Tril backend from JitBuilder to the Test Compiler. The former runs GRA while the latter does not. Running GRA hides this issue by causing arguments to be loaded directly from the argument registers without spilling and reloading.