CR for RFR 8129376

[Vladimir Kozlov]

Okay, goods then. I will sponsor it.

Thanks,
Vladimir

On 9/20/16 4:24 PM, Berg, Michael C wrote:
> Small augment...
>
> -----Original Message-----
> From: Berg, Michael C
> Sent: Tuesday, September 20, 2016 4:22 PM
> To: 'Vladimir Kozlov' <vladimir.kozlov at oracle.com>; hotspot-compiler-dev at openjdk.java.net
> Subject: RE: CR for RFR 8129376
>
> 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 <AVX512> 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
>>