A question on endGroupNode

[Gustavo Romero]

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/ppc/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
>