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

[Andrew Dinn]

Hi Ed,

Looks good to me!

It should not affect the validity of your patch but have you been able
to test it in conditions where Universe::narrow_oop_base() != NULL?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

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