8168318 Use cmpdi instead of li/cmpd

[Lindenmaier, Goetz]

Hi Igor,

> -----Original Message-----
> From: Igor Henrique Soares Nunes [mailto:igor.nunes at eldorado.org.br]
> Sent: Dienstag, 25. Oktober 2016 20:00
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; ppc-aix-port-
> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
> Subject: RE: 8168318 Use cmpdi instead of li/cmpd
> 
> Hi Goetz! Thank you for your respond,
> 
> >Hi,
> 
> >Basically, the new rule looks good.
> 
> >I still wonder why you observe this pattern frequently.  I think
> >n general there should be a CmpN.
> 
> Using PrintOptoAssembly I checked that "li" was being emitted in instruct
> loadConP0or1 followed by cmpP_reg_reg. Basically, I "merged" the match
> rules they implement.
That's what I wanted to know!

> >In which compressed oops mode do you run?  You can check this with
> >-XX:+PrintCompressedOopsMode.
> >There are 4 variants, each with different code to decode/encode the oop:
> >Heap address: 0x00000000c0000000, size: 1024 MB, Compressed Oops
> mode: 32-bit
> >Heap address: 0x0000000100000000, size: 3016 MB, Compressed Oops
> mode: Zero based, Oop shift amount: 3
> >Heap address: 0x0000000800200000, size: 3016 MB, Compressed Oops
> mode: Non-zero disjoint base: 0x0000000800000000, Oop shift amount: 3
> >Heap address: 0x0000000840200000, size: 3016 MB, Compressed Oops
> mode: Non-zero based: 0x0000000840000000, Oop shift amount: 3
> 
> >You can select the variants by specifying where to put the heap:  -
> XX:HeapBaseMinAddress=4G / 32G / 33G
> 
> >Or are you running without compressed oops?
> 
> I was running without compressed oops. I have just reverted locally my
> commit  and ran with the compressed oops (testing the four options you
> listed). And I am still seeing in the dumped assembly the li/cmpld pattern.
> 
> >Also, which node is in[1] of the CmpP that is matched?  Is it a DecodeN?
> 
> >DecodeN is usually  (narrow_oop  << 'Oop shift amount') + 'Heap base'.
> >If Heap base != 0, this does not preserve NULL, thus it is
> >Narrow_oop == 0 ? 0 : (narrow_oop  << 'Oop shift amount') + Heap base.
> 
> I did not understand the right procedure to see the node in in[1]  of the
> matched CmpP. Sorry, I am still a neophyte in openjdk development =(.
> I ran gdb and break in the ppc.ad file in the instruct that I created
> (cmpP_reg_null). After stop, I printed *_in[1], but I did not understand the
> output:
>
> (gdb) print *_in[1]
>  $29 = {_vptr.Node = 0x3fff823e43c8 <vtable for
> loadN2P_unscaledNode+16>, _in = 0x3ffe6c1ff3a8, _out = 0x3ffe6c1ff3e8,
> _cnt = 3, _max = 4, _outcnt = 3, _outmax = 4, _idx = 361, _parse_idx = 361,
>  _class_id = 2, _flags = 4, static NotAMachineReg = 4294901760, _debug_idx =
> 100000361, _debug_orig = 0x0, _hash_lock = 0, _last_del = 0x3ffe6c1fe4c8,
> _del_tick = 1}
> 
> As far as I could see, the matched node is a LoadN2P_unscaled. It is actually a
> "match" that includes decodeN (Set dst (DecodeN (LoadN mem)) ). Is it what
> you meant?
Well, you read the output correctly.  You would also see it in the opto output,
but looking with the debugger is fine, too.
And also that's what I wanted to know.  It's the LoadN2P that causes non-null
checked oops. That makes sense so that's fine and not a problem with/for the 
null check elimination.

Reviewed.
 
> I got stucked in this previous analysis, so I did not proceeded in the further
> topics. I will try to analyze them and answer to you later.
> 
> >Also, have a look at compile.cpp, final_graph_reshaping_impl(), line 3035.
> >Is this code applied wrongly?  It is the preparation of the null check
> optimization
> >in lcm.cpp.
> 
> >Consider that on ppc the page at address
> >'0' is not read protected.  The null check optimization described there
> >only works in 'Non-zero disjoint base' and 'Non-zero based' compressed
> >Oop modes.  In those modes, the first page of the heap is write protected.
> >(See difference between heap address and heap base address in above
> output.)
> >DecodeN_notNull(null) will result in a value that touches that page.
> 
> >Also, please post RFRs to one of the official openJdk lists, in this case
> compiler. Anything
> >pushed to an official repo must be reviewed on these lists.  Ppc-aix-port-
> dev is
> >only for questions wrt. to the port.
> 
> Sorry, I didn´t know that. I will do it the next time.
> 
> >Best regards,
>  > Goetz.
> 
> Thank you,
> Igor Nunes
> 
> 
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> bounces at openjdk.java.net] On Behalf Of Igor Henrique Soares Nunes
> Sent: Donnerstag, 20. Oktober 2016 17:37
> To: ppc-aix-port-dev at openjdk.java.net
> Subject: RFR: 8168318 Use cmpdi instead of li/cmpd
> 
> Hi all,
> 
> The following change, fix the issue addressed in Gustavo's previous e-mail:
> 
> 
> === Use cmpdi instead of li/cmpd (r14 killed after this).
> 3fff60240bec:      li      r14,0
> 3fff60240bf0:      cmpld   cr6,r3,r14
> 
> In order to fix this issue a new instruct was created to match Set crx (CmpP
> src1 src2) when src2 is a null pointer.
> 
> Webrev: https://igorsnunes.github.io/openjdk/webrev/8168318/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8168318
> 
> Thanks,
> 
> Igor Nunes