JDK-6216739 : Missed transforming LoadSignedByte&255 into LoadUnsignedByte
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2005-01-12
  • Updated: 2010-07-29
  • Resolved: 2009-02-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
Description
The expression "((int)b[i] & 0xff))" at line 11 is the unsigned byte
idiom. The compiler should understand that it can simply do an unsigned
load instead of slower (at least on sparc) signed load, and eliminate
the "& 0xff".

- The server compiler (sparc) does this in the pre- and post-loop,
but not the main unrolled loop body. I think the server compiler does
the transformation at code generation time, but the loop unrolling code
moved the LOAD and the AND so far apart that the optimization does not
detected the pattern. 

01 public class CRC32 implements Checksum {
02   private static final int[] crc_table = {...}; /* 256 constants */
03
04   /*  Rolled, use "unsigned byte idiom" */
05   private static int updateBytes(int crc, byte[] b,
06                                  final int off, final int len) {
07     final int[] table = crc_table;
08     final int limit = off + len;
09     crc = crc ^ 0xffffffff;
10     for (int i = off; i < limit; i++) {
11       crc = table[(crc ^ ((int)b[i] & 0xff)) & 0xff]
12             ^ (crc >>> 8);
13     }
14     return crc ^ 0xffffffff;
15   }
16 }
###@###.### 2005-1-12 17:47:52 GMT

Comments
SUGGESTED FIX I'm working on this in 6797305.
05-02-2009

SUGGESTED FIX Create new ideal nodes for LoadUnsignedByte (and LoadUnsignedInt) in the ideal graph, rather than play "pinning" games. ###@###.### 2005-1-12 18:37:27 GMT
12-01-2005

EVALUATION The tranform of LoadSB&255 to LoadUB is done in the matcher. There is code in AndINode::Ideal() that is trying to help out the matcher by pinning the AndINode to the same control node as the LoadSB. Unfortunately, loop-opts changes the control for the LoadSB to allow it to float within the main loop (by pinning it to the loop entry control edge) when it does range check elimination, but the AndINode remains pinned inside the loop. ###@###.### 2005-1-12 17:47:53 GMT ###@###.### 2005-1-12 18:37:27 GMT
12-01-2005