RFR: 8328998: Encoding support for Intel APX extended general-purpose registers

[Jatin Bhateja]

On Fri, 3 May 2024 19:38:08 GMT, Steve Dohrmann <duke at openjdk.org> wrote:

>> How can we be confident that the encoding is correct?  Would it be possible to write tests for this?  Maybe one that disassembles it and compares the result to a 3rd party disassembler offline or in-process hsdis?
>
> In response to @dean-long, @theRealAph wrote:
>> When we wrote the AArch64 port, there was no available hardware to test it on. So, we wrote a simulator to test it. However, we ran the risk that if our understanding of instruction encoding was wrong, our assembler and our simulator might appear to work correctly when used together, but the result would not run on real AArch64 hardware once it arrived. So, as well as a simulator for the architecture, we verified the internal HotSpot assembler by checking its encoding against GNU `as`. See /test/hotspot/gtest/aarch64, where a Python program generates source for both the HotSpot internal assembler and GNU `as`. I strongly suggest you do something similar. (As a matter for the historical record, this did work. The test found several encoding bugs. Once we got the first real AArch64 hardware, the port worked almost immediately.)
> 
> Thanks for the description.  It would be great to create a similar tool for x86.  I tested the encoding manually using the SDE as the authoritative source.  It is tedious though and very time consuming.  
> 
> A subsequent PR in [JDK-8329030](https://bugs.openjdk.org/browse/JDK-8329030), perhaps the one that adds encoding support for New Data Destination variants, should include such a tool.

Hi @steveatgh ,

I have few more comments. 

A) With recent change register only flavors of cvtsi2ss / cvtsi2sd / cvttsd2si/ cvttss2si which are all legacy map 1 instruction and are encoded using REX prefixes at UseAVX=0 will now be promoted to EEVEX which is a fixed 4 byte prefix, we should use REX2 instead.
[cvtsi2ss_MAP1_with_EEVEX.txt](https://github.com/openjdk/jdk/files/15284294/cvtsi2ss_MAP1_with_EEVEX.txt)

B) Memory operand flavor of paddd : 
       Missing EVEX tuples for memory operand instructions, it will prevent applying EVEX compressed displacement (disp8*N) encoding optimization.
      FTR: These are map 1 legacy instruction which could be encoded using SIMD + REX prefix, which adds up to two byte prefix, currently we promote them to VEX encoding in order to zero upper 128 bits, this added additional byte penalty in prefix since it used three byte VEX prefix (c4), now we will encode it using EEVEX if address operands (BASE/INDEX) is a EGPR which will add another byte to prefix since EVEX is a fixed 4 byte prefix. As mentioned above at UseAVX=0 we should encode them using REX2.
[paddd_MAP1_VEX_now_EEVEX.txt](https://github.com/openjdk/jdk/files/15284296/paddd_MAP1_VEX_now_EEVEX.txt)

C)  Memory operand flavor of pcmpestri, ptest and vptest.
 - missing address tuple
 - legacy mode is true should be false.

Kindly incorporate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18476#issuecomment-2106034198