A question on endGroupNode

Fri Feb 3 09:53:25 UTC 2017

Hi Gustavo,

the undesired endgroup instructions were generated by MacroAssembler::set_dest_of_bc_far_at. I had done some cleanup work when implementing and contributing C1. The following change removed these instructions and adapted MacroAssembler::get_dest_of_bc_far_at:
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/4a24de859a87

I don't think replacing these few endgroup by the preferred nop instructions will show a measurable performance benefit, so we didn't backport it.

Best regards,
Martin

-----Original Message-----
From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] 
Sent: Donnerstag, 2. Februar 2017 19:20
To: Doerr, Martin <martin.doerr at sap.com>; ppc-aix-port-dev at openjdk.java.net
Subject: Re: A question on endGroupNode

Hi Martin,

On 01-02-2017 11:19, Doerr, Martin wrote:
> Hi Gustavo,
> 
> I can't see how endGroup nodes can get generated in the current jdk9 code.
> If I remember correctly, endgroup instructions were emitted in conditional long branches when the branch destination is near. But this code is gone in the current jdk9 code.
> Are you using an older version?

Yes, the ori r1,r1,0 on Hive was collected from 8. It's OpenJDK 8 on RHEL 7.2:

java -version
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-b15) OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)

java-1.8.0-openjdk.ppc64le 1:1.8.0.111-1.b15.el7_2 @local-rhn-server-os java-1.8.0-openjdk-devel.ppc64le 1:1.8.0.111-1.b15.el7_2 @local-rhn-server-os java-1.8.0-openjdk-headless.ppc64le 1:1.8.0.111-1.b15.el7_2 @local-rhn-server-os

Red Hat packages OpenJDK 8 from:
http://hg.openjdk.java.net/aarch64-port/jdk8u/tags (tag: aarch64-jdk8u111-b15), that by its turn derives from tag jdk8u102-b14 on jdk8u/jdk8u, so it brings at least all the changes in jdk8u/jdk8u tag jdk8u102-b14.

When I used the SPECjvm2008 (plus -XX:+PrintOptoAssembly) to find out other occurrences of ori r1,r1,0 (without success) I used jdk8u/jdk8u tip.

However I could not find a change on jdk8u/jdk8u regarding the endGroupNode specifically.

On 9, your patch "8170991: PPC64: Bad code for initialization of short arrays"
removed the emission of it by removing the call to endgroup() in
MacroAssembler::clear_memory_doubleword() but in that case the ori r1,r1,0 would be preceded by a bdnz instruction and not beq or bge. But even so, it's guarded by if (InsertEndGroupPPC64), which is by default false.

I don't know yet from which case the ori r1,r1,0 in question comes from. I'll try to run Hive against a debug build with -XX:+PrintOptoAssembly to check if the annotation revels its origin exactly. I understand it comes from a C2 compilation.

> The purpose of endgroup instructions is to optimize for Power6. They should get inserted before control flow merge points if the instruction group is not already completed. We have a special Power6 instruction scheduler which takes care of that, but we haven't contributed it. I guess Power6 optimization is not so relevant any more.
hm, right.

Thanks!

Best regards,
Gustavo

> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: ppc-aix-port-dev 
> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of 
> Gustavo Romero
> Sent: Dienstag, 31. Januar 2017 12:19
> To: ppc-aix-port-dev at openjdk.java.net
> Subject: A question on endGroupNode
> Importance: High
> 
> Hi,
> 
> Sometimes the JVM on PPC64 puts a group ending nop (ori r1,r1,0) after 
> conditional branches, like, for instance, the following assembly 
> sequence from
> C2 generated from Hive code:
> 
>    379 6.6e-04 :    10000980436c:       lwz     r14,16(r6)
>    816  0.0014 :    100009804370:       cmplw   cr6,r7,r14
>                :    100009804374:       bge     cr6,100009804ee8
>                :    100009804378:       ori     r1,r1,0   <=== endGroup
>    167 2.9e-04 :    10000980437c:       add     r15,r7,r8
>    892  0.0015 :    100009804380:       addi    r17,r15,-1
>                :    100009804384:       cmplw   cr5,r17,r14
>                :    100009804388:       bge     cr5,100009804ee8
>    262 4.5e-04 :    10000980438c:       ori     r1,r1,0   <=== endGroup
>    648  0.0011 :    100009804390:       li      r14,0
>                :    100009804394:       cmpld   cr6,r5,r14
>                :    100009804398:       beq     cr6,100009804ee8
>    267 4.6e-04 :    10000980439c:       ori     r1,r1,0   <=== endGroup
>    930  0.0016 :    1000098043a0:       addis   r20,r29,384
>                :    1000098043a4:       addi    r20,r20,16384
> 
> The (ori r1, r1, 0) seems to be emitted from a endGroupNode defined in:
> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/6c1e79a99176/src/cpu/p
> pc/vm/ppc.ad#l13261
> 
> Nonetheless, I could not generated any endGroupNode using SPECjvm2008 (i.e.
> looking at the log from -XX:+PrintOptoAssembly there is no "End Bundle" anywhere).
> 
> Any idea why it exists primarily and if there is any option to control its emission or even a particular way to avoid the creation of an endGroupNode?
> 
> Thank you.
> 
> 
> Best regards,
> Gustavo
> 