Sign extend 32bit offsets in inlineIntrinsicInflate

[klangman]

Without sign extending the 32bit offsets, it is possible for the upper 32bits of the offset registers to contain garbage bits that will cause the address calculations to produce incorrect (unaddressable) results.

[klangman]

@IBMJimmyk @zl-wang This fixes the problem that we talked about a few weeks back. My personal build (for all POWER platforms) passed.

[IBMJimmyk]

It looks good to me.

[zl-wang]

Did you find out the specific situation where garbage upper 32bits made its way into register?
This PR certainly fixed your particular issue on hand, but it might miss the real culprit at large. Appreciate it if that can be found out. I think codegen should be expected to produce correct values in full register.

[klangman]

Did you find out the specific situation where garbage upper 32bits made its way into register?

In the failing case the caller of String.getChars() calculates the 1st parameter (srcBegin) to be the return from String.lastIndexOf() using a parameter string that is not contained in the 'this' String, then it adds one. Since lastIndexOf() returns -1 (0xffffffff), and then we add 1 we get (0x100000000) in the 64bit register. This value is passed to String.getChars() which needs to be 32bit sign extended to be a proper 64bit 0.

Here is the test-case:

public class getCharsCrash {
   public static void main(String argv[]){
      for( int i=0 ; i< 5000 ; i++ ) {
         test(argv[0]);
      }
   }

   static void test(String str) {
      char dest[] = new char[128];
      int begin = str.lastIndexOf("missing");
      System.out.println("begin: " + begin);
      begin++;
      str.getChars(begin, str.length()-1, dest, 0);
      System.out.println("dest: " + new String(dest));
   }
}

With the right inlining restrictions this test-case crashes in String.getChars().