CR for RFR 8178800
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu May 11 16:57:02 UTC 2017
Updated webrev:
http://cr.openjdk.java.net/~mcberg/8178800/webrev.02/
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
>>
More information about the hotspot-compiler-dev
mailing list