[aarch64-port-dev ] RFR: aarch64: elide DecodeN when followed by CmpP 0

[Hui Shi]

Hi Edward,

A newbie question, how to determine "DecodeN" result is not used later, is
there some use count here?

+  match(If cmp (CmpP (DecodeN oop) zero));+
predicate(n->in(1)->as_Bool()->_test._test == BoolTest::ne+
|| n->in(1)->as_Bool()->_test._test == BoolTest::eq);


  0x000003ff9d3e8920: ldr w11, [x1,#16]
  0x000003ff9d3e8924: lsl x10, x11, #3
  0x000003ff9d3e8928: cbnz x10, 0x000003ff9d3e8950

Even X10 is used in later code, is it slightly better make them into
following form? Later two instructions are not dependent.
  0x000003ff9d3e8920: ldr w11, [x1,#16]
  0x000003ff9d3e8924: lsl x10, x11, #3
  0x000003ff9d3e8928: cbnzw w11, 0x000003ff9d3e8950


Regards
Shi Hui

On 16 September 2015 at 22:41, Edward Nevill <edward.nevill at gmail.com>
wrote:

> Hi,
>
> Please review the following webrev
>
> http://cr.openjdk.java.net/~enevill/8136615/webrev/
>
> JIRA issue here: https://bugs.openjdk.java.net/browse/JDK-8136615
>
> C2 currently generates code like
>
>   0x000003ff9d3e8920: ldr w11, [x1,#16]
>   0x000003ff9d3e8924: lsl x10, x11, #3
>   0x000003ff9d3e8928: cbnz x10, 0x000003ff9d3e8950
>
> when doing a pointer comparison against 0
>
> The lsl instruction is generated by a DecodeN node which can be elided in
> this case.
>
> The following is a simple test case
>
> public class decode {
>     public static void main(String[] args) {
>         if (args[0] != null) {
>           System.out.println("not null");
>         }
>     }
> }
>
> java -XX:-TieredCompilation -Xcomp -XX:CompileOnly=decode::main
> -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+PrintOptoAssembly
> -XX:+PrintIdeal decode
>
> The above is a trivial case, but I have seen many of these redundant lsl
> instructions generated in various list chasing code.
>
> Tested with jtreg hotspot and langtools with no regressions.
>
> Thanks for your review,
> Ed.
>
>
>