RFR(L): 8081247 AVX 512 extended support code review request

Berg, Michael C michael.c.berg at intel.com
Sat Jun 20 09:06:21 UTC 2015


With this link:

http://cr.openjdk.java.net/~mcberg/8081247/webrev.04/

Thanks,
Michael


-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Berg, Michael C
Sent: Saturday, June 20, 2015 2:03 AM
To: Vladimir Kozlov; 'hotspot-compiler-dev at openjdk.java.net'
Subject: RE: RFR(L): 8081247 AVX 512 extended support code review request

Vladimir, please see the latest upload, revsion4, which has my changes tested on SSE,AVX,EVEX.

Thanks,
-Michael

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Friday, June 19, 2015 11:58 AM
To: Berg, Michael C; 'hotspot-compiler-dev at openjdk.java.net'
Subject: Re: RFR(L): 8081247 AVX 512 extended support code review request

JPRT testing did not pass - a lot of failures (run all hotspot/test/* jtreg tests):

Terminal Rampup began Fri Jun 19 20:38:51 CEST 2015 for 0.5 minutes
o467	ReplicateI	=== _ o75  [[o468 ]]  #vectorx[4]:{int}

--N: o467	ReplicateI	=== _ o75  [[o468 ]]  #vectorx[4]:{int}

    --N: o75	ConI	=== o0  [[o465 o469 o322 o220 o223 o467 o323 o292 o293 
o294 o321 ]]  #int:1
    IMMI  10  IMMI
    IMMI1  0  IMMI1
    IMMI2  0  IMMI2
    IMMI8  5  IMMI8
    IMMI16  10  IMMI16
    IMMU31  0  IMMU31
    RREGI  100  loadConI
    RAX_REGI  100  loadConI
    RBX_REGI  100  loadConI
    RCX_REGI  100  loadConI
    RDX_REGI  100  loadConI
    RDI_REGI  100  loadConI
    NO_RCX_REGI  100  loadConI
    NO_RAX_RDX_REGI  100  loadConI
    STACKSLOTI  200  storeSSI

# To suppress the following error report, specify this argument # after -XX: or in .hotspotrc:  SuppressErrorAt=/matcher.cpp:1602 # # A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (hotspot/src/share/vm/opto/matcher.cpp:1602),
pid=4714, tid=0x000000004090e950
#  assert(false) failed: bad AD file
#

And

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(/opt/jprt/T/P1/181115.vkozlov/s/hotspot/src/cpu/x86/vm/assembler_x86.cpp:3060),
pid=6301, tid=0x000000004226e950
#  assert((UseAVX > 0)) failed: SSE mode requires address alignment 16 bytes # V  [libjvm.so+0x110ae41]  VMError::report_and_die()+0x151 V  [libjvm.so+0x7f65eb]  report_vm_error(char const*, int, char const*, char const*)+0x7b V  [libjvm.so+0x4afaa4]  Assembler::pshufd(XMMRegisterImpl*, Address,
int)+0x234
V  [libjvm.so+0x2a003e]  Repl2D_memNode::emit(CodeBuffer&,
PhaseRegAlloc*) const+0x25e
V  [libjvm.so+0x765923]  Compile::scratch_emit_size(Node const*)+0x463 V  [libjvm.so+0xe72794]  Compile::shorten_branches(unsigned int*, int&, int&, int&)+0x204 V  [libjvm.so+0xe73897]  Compile::init_buffer(unsigned int*)+0x2d7 V  [libjvm.so+0xe7efb7]  Compile::Output()+0x8c7

Vladimir

On 6/4/15 9:46 PM, Berg, Michael C wrote:
> Vladimir please find the following webrev with the suggested changes, I have added small signature functions which look like the old versions  in the assembler but manage the problem I need to handle, which is additional state for legacy only instructions. There is a new vm_version function which handles the cpuid checks with a conglomerate approach for the one scenario which had it.
> The loop in the stub generator is now formed to alter the upper bound and execute in one path.
>
> http://cr.openjdk.java.net/~mcberg/8081247/webrev.03/
>
> Regards,
> Michael
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Wednesday, June 03, 2015 6:10 PM
> To: Berg, Michael C; 'hotspot-compiler-dev at openjdk.java.net'
> Subject: Re: RFR(L): 8081247 AVX 512 extended support code review 
> request
>
> Hi, Michael
>
> assembler_x86.cpp:
>
> I don't like that you replaced prefix method with few parameters with method which has a lot of them:
>
> -  int encode = vex_prefix_0F38_and_encode_q(dst, src1, src2);
> +  int encode = vex_prefix_and_encode(dst->encoding(),
> + src1->encoding(),
> src2->encoding(),
> +                                     VEX_SIMD_NONE, VEX_OPCODE_0F_38,
> true, AVX_128bit,
> +                                     true, false);
>
> Why you did that?
>
>
> stubGenerator_x86_64.cpp:
>
> Can we set different loop limit based on UseAVX instead of having 2 loops.
>
> x86.ad:
>
> Instead of long condition expressions like next:
>
> UseAVX > 0 && !VM_Version::supports_avx512vl() &&
> !VM_Version::supports_avx512bw()
>
> May be have one VM_Version finction which does these checks.
>
> Thanks,
> Vladimir
>
> On 6/2/15 9:38 PM, Berg, Michael C wrote:
>> Hi Folks,
>>
>> I would like to contribute more AVX512 enabling to facilitate support 
>> for machines which utilize EVEX encoding. I need two reviewers to 
>> review this patch and comment as needed:
>>
>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8081247
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~mcberg/8081247/webrev.01/
>>
>> This patch enables BMI code on EVEX targets, improves replication 
>> patterns to be more efficient on both EVEX enabled and legacy 
>> targets, adds more CPUID based rules for correct code generation on 
>> various EVEX enabled servers, extends more call save/restore 
>> functionality and extends the vector space further for SIMD 
>> operations.  Please expedite this review as there is a near term need for the support.
>>
>> Also, as I am not yet a committer, this code needs a sponsor as well.
>>
>> Thanks,
>>
>> Michael
>>


More information about the hotspot-compiler-dev mailing list