RFR (S) : 8014362 : Need to expose some processor features via	Unsafe interface
    Aleksey Shipilev 
    aleksey.shipilev at oracle.com
       
    Fri May 10 13:44:41 PDT 2013
    
    
  
On 05/11/2013 12:33 AM, David Chase wrote:
> FIX:
> 1) add a bit to cpuFeatureFlags for CLMUL.
> 2) expose the CLMUL bit in StdCpuid1Ecx
> 3) add a flag (in the style of UseAES)
> 4) add an unsafe intrinsic.
5) provide fast-path for C1 in c1_GraphBuilder.cpp
6) provide fast-path for C2 in library_call.cpp
> And connect all those dots.
> 
> The unsafe interface returns UseAVX and UseCLMUL because both are necessary to obtain the 3-operand version of the CLMUL instruction.
I'm not sure Unsafe is a good place to have this: while this is the door
into the VM land, Unsafe itself seems generic enough. I think we might
want to have the sun.misc.CPUFeatures or something like that?
But by far the better option seems to invert control: expose the
PCLMULQDQ-compatible method on Java side, and then intrinsify it in
compiler, like we do with AES. See vmSymbols.hpp and library_call.cpp,
search for "_aescrypt_encryptBlock".
-Aleksey.
    
    
More information about the hotspot-compiler-dev
mailing list