CR for RFR 8178800

Berg, Michael C michael.c.berg at intel.com
Thu May 11 00:05:46 UTC 2017


Hi Vladimir,

See below for explanations...

Regards,
Michael

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Wednesday, May 10, 2017 4:55 PM
To: Berg, Michael C <michael.c.berg at intel.com>; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: CR for RFR 8178800

Hi Michael,

Why do you need pshufd()?
<MCB> I found it possible for auto code generation to emit this pattern in memory form, ergo I added the support so that if the dst register is in the upper bank on vector length constrained instructions (128bit, 256bit, etc), that we could encode with VEX on KNL.

Why to save xmm0 in register you can use movdqu() but for stack you use evmovdqul()?
<MCB> I will make that consistent too, and change to the full register version.

Why you can use movss(src, nds) and movsd(src, nds) when other instructions use evmovdqul() for that?
<MCB> For consistency sake I will make the change, semantically it does not mater though.

Why you removed (nds_enc < 16) block?
<MCB> Because the code I found I needed was exactly the same for that case and the final case, ergo I removed some code.

<MCB> Would these changes suffice? They cosmetic in nature, so I will limit my testing.

Thanks,
Vladimir


On 5/10/17 12:58 PM, Berg, Michael C wrote:
> Hi Folks,
>
> Some support was added to enable a pass state of all validation tests 
> for KNL for JDK9.  This support enables upper bank register usage for 
> auto code generation for a small number of instructions (3) which 
> needed some additional coverage under cases where servers do not 
> enable vector length but have EVEX support.
>
>
>
> This code was tested as follows: All internal validation tests at both 
> Intel and Oracle.  This change needs approval for JDK9 addition.
>
>
> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8178800
>
>
> webrev: http://cr.openjdk.java.net/~mcberg/8178800/webrev
>
>
>
> Regards,
>
> Michael
>


More information about the hotspot-compiler-dev mailing list