RFR: 8328998: Encoding support for Intel APX extended general-purpose registers [v4]
Sandhya Viswanathan
sviswanathan at openjdk.org
Fri Apr 26 18:10:55 UTC 2024
On Fri, 19 Apr 2024 21:51:45 GMT, Steve Dohrmann <duke at openjdk.org> wrote:
>> Add instruction encoding support for Intel APX extended general-purpose registers:
>>
>> Intel Advanced Performance Extensions (APX) doubles the number of general-purpose registers, from 16 to 32. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html.
>>
>> By specification, instruction encoding remains unchanged for instructions using only the lower 16 GPRs. For cases where one or more instruction operands reference extended GPRs (Egprs), encoding targets either REX2, an extension of REX encoding, or an extended version of EVEX encoding. These new encoding schemes extend or modify existing instruction prefixes only when Egprs are used.
>
> Steve Dohrmann has updated the pull request incrementally with one additional commit since the last revision:
>
> bug fix in other ::prefix_rex2
src/hotspot/cpu/x86/assembler_x86.cpp line 13260:
> 13258: } else {
> 13259: emit_int24((prefix & 0xFF00) >> 8, prefix & 0x00FF, b1);
> 13260: }
We need a check for UseAPX > 0 here.
src/hotspot/cpu/x86/assembler_x86.cpp line 14004:
> 14002: int encode = prefixq_and_encode(dst->encoding(), src->encoding(), true);
> 14003: emit_opcode_prefix_and_encoding((unsigned char)0xB8, 0xC0, encode);
> 14004: }
void Assembler::popcntq(Register dst, Address src) also need to be handled for rex2 generation. get_prefixq() will return a 16 bit entity and so call to emit_int32 directly is not correct.
emit_int32((unsigned char)0xF3,
get_prefixq(src, dst),
0x0F,
(unsigned char)0xB8);
Likewise void Assembler::cvttsd2siq(Register dst, Address src) also needs to be updated to handle extended gprs.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18476#discussion_r1581333389
PR Review Comment: https://git.openjdk.org/jdk/pull/18476#discussion_r1581329964
More information about the hotspot-compiler-dev
mailing list