Request for reviews (M): 8004835: Improve AES intrinsics on x86
suenaga.yasumasa at lab.ntt.co.jp
Mon Dec 17 20:29:08 PST 2012
Thank you for the explanation.
I've not read 319433-014.pdf .
On 2012/12/18 5:52, Vladimir Kozlov wrote:
> 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
> 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
>> on a 16-byte boundary or a general-protection exception (#GP) will be
>> 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() .
>> 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.
More information about the hotspot-compiler-dev