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

[Vladimir Kozlov]

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 
quote.

> 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):

http://software.intel.com/sites/default/files/319433-014.pdf

(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.

Thanks,
Vladimir

> So I think that assert condition for AVX does not required in
> Assembler::pshufb() .
>
> http://download.intel.com/products/processor/manual/325383.pdf
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2012/12/16 7:09, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8004835/webrev/
>>
>> 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