CR for RFR 8129376

[Berg, Michael C]

Vladmir,

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 change was applied now.

Regards,
Michael

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Tuesday, September 20, 2016 4:16 PM
To: hotspot-compiler-dev at openjdk.java.net
Cc: Berg, Michael C <michael.c.berg at intel.com>
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.

Thanks,
Vladimir

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: https://bugs.openjdk.java.net/browse/JDK-8129376
>
>
> webrev:
>
> http://cr.openjdk.java.net/~mcberg/8129376/webrev.01
>
> Regards,
>
> Michael
>