i#2626 fp/simd encode: Add support for most FP Neon instructions.

[fhahn]

This patch adds encoding & decoding support for most arithmetic FP Neon
instructions. The structure of the generated macros and tests follows
the style of #2896.

codec.txt contains comments if not all encodings of an instruction are
supported yet. Also missing are the Arm v8.3-a FCADD and FCMLA
instructions, because their rotation arguments require a bit of special
handling to get nice macros.

Issue #2626

[fhahn]

@derekbruening I could also split this one into smaller patches, if that would make things easier to review. Most of the changes are only mechanical though

[derekbruening]

Ideally I would go look in the manual and verify (at least spot-check a few of) the binary encodings for a thorough review -- has there been a cross-checking versus an existing decoder/encoder?

[derekbruening]

I spot-checked just FMADD and it seems the bit after the 5 1's (bit 23) can be 0 and not x?

[fhahn]

According to the A64 ISA XML [1], bits 22 and 23 of FMADD (and other FP instructions) encode the element type (00 = Single, 01 = double, 11 = Half). xx here means it is set by (at least) one of the operands, in that case that case float_reg0, float_reg5, float_reg16, float_reg10. The actual encoding of the type is done here.

[1] https://developer.arm.com/products/architecture/a-profile/exploration-tools

[derekbruening]

In the ARM Architecture Reference Manual for ARMv8, maybe old since from 2013 ARM DDI 0487A.a (ID090413), the FMADD entry in C6.3.87 on page C6-924 says:

31 30 29 28 27 26 25 24 23 22 21 20    16 15 14    10 9    5 4    0
 0  0  0  1  1  1  1  1  0  x  0       Rm  0    Ra      Rn     Rd
                         type o1          o0

I.e., it is saying that the top bit of the type is always 0 -- meaning the half type is not supported. Yet encode_opnd_float_reg() will accept half.

[fhahn]

Ah yes. The half encodings were added in Arm v8.2. That leads us to an interesting question: How should we deal with that? I also realized that there is no comment indicating that the half version is 8.2.

[derekbruening]

For x86 we do not treat processor revisions as first-class in the encoder/decoder: it will accept a newer encoding when running on an older processor (and deal with it for execution only when SIGILL is raised) so it doesn't seem so bad to keep it how you have it, with perhaps as you say a comment in encode_opnd_float_reg() saying that a half type on 8.1 is illegal.

[fhahn]

Great thanks for having a look. Will do that tomorrow.

[derekbruening]

Xref the drcpusim tool [1] which has its own accounting of which encodings are valid on which processor because the DR ISA doesn't tell it. Its use case is an app that contains different assembly sequences for different architectures (such as optimized multimedia code) and wants to test that it's using only legal instructions on some legacy processor. (Would such a tool be useful for ARM as well or does ARM already provide such a tool?)

[1] http://dynamorio.org/docs/page_drcpusim.html

[fhahn]

I do not think Arm currently provides such a tool, but I suppose it could be useful once more hardware implementing different version of Armv8 becomes available.

We discussed providing some kind of API to check which version of the ISA supports an encoding internally. I've created #2960 to discuss the details.

[fhahn]

The dis-a64 test should verify that binutils and our assembler/disassembler agree on the test cases in suite/tests/api/dis-a64.txt. The line should contain :

Encoding (generated by binutils in this patch) : assembly string : expected DynamoRIO IR

For each line, dis-a64 should read the encoding, disassemble it, compare the resulting IR to the expected and assemble the IR and check if it matches the original encoding. I think that's pretty good, but of course it would not catch our disassembler accepting invalid encodings for example.

[fhahn]

That said, I think we could improve on the negative testing, e.g. checking we fail encoding invalid IR.

[derekbruening]

Approving in anticipation of comment(s) on the half type.

[fhahn]

Thank you very much Derek for your quick feedback!