CR for RFR 8129376

Berg, Michael C michael.c.berg at
Tue Sep 20 23:24:19 UTC 2016

Small augment...

-----Original Message-----
From: Berg, Michael C 
Sent: Tuesday, September 20, 2016 4:22 PM
To: 'Vladimir Kozlov' <vladimir.kozlov at>; hotspot-compiler-dev at
Subject: RE: CR for RFR 8129376


The way they were versed they caused allocation issues on part of the xmm bank for client only. 
I believe I ran with both tiered off and inlining off while sleuthing the issue and after I applied the change as part of my verification process.  I tested client and server 32-bit.
With the change applied 32-bit server performance does not seem affected.  The generated code looks like it did before the <AVX512> change was applied now.


-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at]
Sent: Tuesday, September 20, 2016 4:16 PM
To: hotspot-compiler-dev at
Cc: Berg, Michael C <michael.c.berg at>
Subject: Re: CR for RFR 8129376

Changes look good.

Michael, can you explain how pads affected code generation to cause regression?
.ad changes affects Server VM (c2) code generation. Do you need it based on performance numbers? TRy running Server VM with -XX:-TieredCompilation.


On 9/20/16 4:02 PM, Berg, Michael C wrote:
> Hi Folks,
> Performance on client x86 targets was hampered in two SPECjvm98 
> metrics (mpegaudio and  mtrt) for 32-bit since we added AVX512.  I 
> also checked to make sure only client on x86-32 was affected.  I have mitigated this by altering the xmm pad modeling in the x86-32-bit machine description so that register allocation cannot see the dummy definitions, enabling the desired performance while retaining correctness for 32-bit on AVX512.
> This code was tested as follows: hotspot jreg, SPECjvm2008, SPECjvm98 on hsw, skx and knl targets complete with no issues on 32-bit.  These changes do not alter behavior on x86-64.
> Bug-id:
> webrev:
> Regards,
> Michael

More information about the hotspot-compiler-dev mailing list