Request for reviews (M): 8004835: Improve AES intrinsics on x86

Vladimir Kozlov vladimir.kozlov at
Mon Dec 17 12:52:48 PST 2012

Hi, Yasumasa

Thank you for looking on changes.

On 12/16/12 5:02 PM, Yasumasa Suenaga wrote:
> Hi Vladimir,
> Source operand of Assembler::pshufb() seems to allow misaligned memory
> address.

I assume you mean "to NOT allow" otherwise you statement contradict the 

> Instruction reference of PSHUFB says following:
> ----------
> When the source operand is a 128-bit memory operand, the operand must be
> aligned
> on a 16-byte boundary or a general-protection exception (#GP) will be
> generated.
> ----------
> Not only non-AVX but also AVX CPU needs 16-byte aligned memory address
> for source
> operand of PSHUFB.

It is not true. It depends how you encode instructions when AVX 
available. Hotspot use VEX prefix in such case with which alignment is 
not required (2.5):

(v)pshufb is "Type 4" exception class instruction (Table 2-7). For such 
instructions only legacy SSE encoded (REX prefix) instructions cause #GP 
exception with unaligned memory (Table 2-13). Note, in 325383.pdf 
corresponding tables are 2-14 and 2-20.


> So I think that assert condition for AVX does not required in
> Assembler::pshufb() .
> Thanks,
> Yasumasa
> On 2012/12/16 7:09, Vladimir Kozlov wrote:
>> Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction
>> in load_key() method could be used without AVX because it references
>> only aligned memory "key_shuffle_mask".
>> Group together aes instructions in encryptBlock/decryptBlock stubs as
>> recommended by Intel Optimization Guide.
>> Modified test/compiler/7184394 to test "ECB" mode.
>> Ran compiler regression tests and jdk crypto and security tests with
>> SunJCE default provider.
>> Thanks,
>> Vladimir

More information about the hotspot-compiler-dev mailing list