JDK-8001436 : C2: Implement bitwise constant propagation
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 14
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2012-10-24
  • Updated: 2019-10-15
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.
Related Reports
Relates :  
Relates :  
In type.[ch]pp, to TypeInt and TypeLong, add bitwise constant information.

Specifically, in addition to arithmetic upper and lower bounds _hi and _lo, add bitwise upper and lower bounds, _up and _dn.

Push this information through TypePtr offsets, to track alignment information.

Use this information to help decide if ALU operations can be strength reduced.

The bit equations can be derived with some thought.  A working Java prototype is attached (creation date is 4/18/2007, by jrose).
Reopening unbound from releases. In the future when we do more with vector types (wider than 64 bits) bitwise type information will become even more important to track. Likewise, when we do more with raw pointers (machine addresses in Panama wrappers) we will want to make inferences about pointer alignment, which arises naturally from inspecting the low bits of a bitwise type. This feature is "in Graal" partially but the lifted arithmetic is only partially implemented, and the bitwise bounds are not systematically exploited. Many operators that infer tight upper and lower arithmetic bounds neglect to also infer tight bitwise bounds, even when the calculation would be simple.

This is already supported by Graal. Adding wnf-candidate label because it's not clear if we have the resources to implement this in C2.

C2 associates an offset with all pointer types. If this offset is also made to carry bitwise information (at least in the low bits), it can be used to reason about the alignment of data elements accessed by a vectorized loop. Given that the GC manages the base of (many) pointers, the higher bits might not be so determinable, unless we add a new invariant to array allocation, by which larger arrays are aligned more strictly, in order to support aligned access beyond 64 bits in size.

For an example of an implementation using such masks, see upMask and downMask in these files: http://hg.openjdk.java.net/graal/graal/file/tip/graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IntegerStamp.java http://hg.openjdk.java.net/graal/graal/file/tip/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.java http://hg.openjdk.java.net/graal/graal/file/tip/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerTestNode.java http://hg.openjdk.java.net/graal/graal/file/tip/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitCountNode.java