Quantcast

CR for RFR 8178800

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CR for RFR 8178800

Berg, Michael C

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: CR for RFR 8178800

Berg, Michael C

Some additional notes, the vabsss and vabssd instructions utilize a test on src2 vs dst, this is required as the live range of src2 can end making it available for reuse, in such a case, we manage and use xmm0 so that we have a scratch register to utilize which will facilitate VEX encoding.

 

Regards,

Michael

 

From: hotspot-compiler-dev [mailto:[hidden email]] On Behalf Of Berg, Michael C
Sent: Wednesday, May 10, 2017 12:59 PM
To: '[hidden email]' <[hidden email]>
Subject: CR for RFR 8178800

 

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CR for RFR 8178800

Vladimir Kozlov
In reply to this post by Berg, Michael C
Hi Michael,

Why do you need pshufd()?

Why to save xmm0 in register you can use movdqu() but for stack you use
evmovdqul()?

Why you can use movss(src, nds) and movsd(src, nds) when other
instructions use evmovdqul() for that?

Why you removed (nds_enc < 16) block?

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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: CR for RFR 8178800

Berg, Michael C
Hi Vladimir,

See below for explanations...

Regards,
Michael

-----Original Message-----
From: Vladimir Kozlov [mailto:[hidden email]]
Sent: Wednesday, May 10, 2017 4:55 PM
To: Berg, Michael C <[hidden email]>; '[hidden email]' <[hidden email]>
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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CR for RFR 8178800

Vladimir Kozlov
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:[hidden email]]
> Sent: Wednesday, May 10, 2017 4:55 PM
> To: Berg, Michael C <[hidden email]>; '[hidden email]' <[hidden email]>
> 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
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CR for RFR 8178800

Tobias Hartmann-2
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:[hidden email]]
>> Sent: Wednesday, May 10, 2017 4:55 PM
>> To: Berg, Michael C <[hidden email]>; '[hidden email]' <[hidden email]>
>> 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
>>>
Loading...