RFR: aarch64: elide DecodeN when followed by CmpP 0

[Vladimir Kozlov]

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

On 9/16/15 7:41 AM, Edward Nevill 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.
>
>