RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI.

[Vladimir Ivanov]

> Thanks for testing the patch.
> To be on the safe side,  I am preserving the rcx register and don't want to introduce any new bugs.

Thinking more about this, I came to the conclusion that I don't fully 
understand what is the motivation to add the code in 
MA::restore_cpu_control_state_after_jni().

If there are other instructions left which are affected by the same 
encoding problem, resetting k1 after JNI call is not sufficient to hide 
the problem (e.g., any call into the JVM can potentially use k1).

Moreover, C2 w/ PostLoopMultiversioning (turned off by default) produces 
post loops with k1 usage, but doesn't reset it.

So, it seems it doesn't fix anything, but makes hitting similar bug less 
likely.

Best regards,
Vladimir Ivanov

> -----Original Message-----
> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com]
> Sent: Thursday, November 30, 2017 1:29 PM
> To: Deshpande, Vivek R <vivek.r.deshpande at intel.com>; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI.
> 
>> http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/
> 
> Thanks, Vivek. I verified that the reported problem goes away with the fix.
> 
> src/hotspot/cpu/x86/macroAssembler_x86.cpp
> 
> +  // Reset k1 to 0xffff.
> +  if (VM_Version::supports_evex()) {
> +    push(rcx);
> +    movl(rcx, 0xffff);
> +    kmovwl(k1, rcx);
> +    pop(rcx);
> +  }
> 
> Why do you preserve rcx which is already caller-saved and shouldn't contain anything valuable after a JNI call?
> 
> Best regards,
> Vladimir Ivanov
>