RFR(L): 8081247 AVX 512 extended support code review request
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Jun 19 18:58:10 UTC 2015
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