CR for RFR 8178800

[Tobias Hartmann]

Hi,

On 11.05.2017 18:57, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~mcberg/8178800/webrev.02/

This looks good to me.

Best regards,
Tobias

> On 5/10/17 5:05 PM, Berg, Michael C wrote:
>> 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.
> 
> Okay, I see now. You replaced Assembler::pshufd() calls with memory parameter with MacroAssembler::pshufd() to use vex encoding.
> 
>>
>> 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.
> 
> Ok.
> 
>>
>> 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.
> 
> Ok.
> 
>>
>> 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.
> 
> Ok.
> 
>>
>> <MCB> Would these changes suffice? They cosmetic in nature, so I will limit my testing.
> 
> Yes. But we will run our RBT testing again.
> 
> Thanks,
> Vladimir
> 
>>
>> 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
>>>