RFR: aarch64: elide DecodeN when followed by CmpP 0

Edward Nevill edward.nevill at gmail.com
Wed Sep 23 22:12:07 UTC 2015

On Wed, Sep 16, 2015 at 5:06 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> This is strange. Ideal graph should have CmpN in such case.
> See Compile::final_graph_reshaping_impl() case Op_CmpP:
> Please, look why CmpP is not converted in your case?
> Thanks,
> Vladimir

Hi Vladimir.

The reason CmpN is not generated in the case of aarch64 is the following
test in final_graph_reshaping

           if (Matcher::gen_narrow_oop_implicit_null_checks())
            new_in2 = ConNode::make(TypeNarrowOop::NULL_PTR);

This test converts the CmpP to CmpN if implicit null checks are being

For aarch64 the test above always returns false because
Matcher::narrow_oop_use_complex_address() in aarch64.ad returns false.

The rational behind this seems to be that it is better to generate

          //    Load_narrow_oop memory, narrow_oop_reg
          //    Load [R12 + narrow_oop_reg<<3 + offset], val_reg
          //    NullCheck narrow_oop_reg

on architectures which support complex addresses (eg x86) and

          //    Load_narrow_oop memory, narrow_oop_reg
          //    decode_not_null narrow_oop_reg, base_reg
          //    Load [base_reg + offset], val_reg
          //    NullCheck base_reg

on architectures which do not (eg aarch64, sparc, ppc).

The problem is that this code assumes we are doing a load, whereas in my
test case

public class decode {
     public static void main(String[] args) {
         if (args[0] != null) {
           System.out.println("not null");

there is no load, it is just doing a check on a null pointer.

All the best,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150923/5d134a15/attachment.html>

More information about the hotspot-compiler-dev mailing list