[PATCH] D39091: [AArch64][SVE] Asm: Add support for (ADD|SUB)_ZZZ

[Sander de Smalen via Phabricator via llvm-commits]

sdesmalen added inline comments.


================
Comment at: test/MC/AArch64/SVE/assembler_tests/add.s:3
+// RUN: not llvm-mc -triple=aarch64-none-linux-gnu -show-encoding -mattr=-sve 2>&1 < %s | FileCheck --check-prefix=CHECK-ERROR %s
+add     z31.s, z31.s, z31.s  // 00000100-10111111-00000011-11111111
+// CHECK: add     z31.s, z31.s, z31.s // encoding: [0xff,0x03,0xbf,0x04]
----------------
asb wrote:
> I'm probably showing my ignorance here, but what's with the binary in these comments and CHECK-ERROR-NEXT?
No, you're right, I don't think they are used anymore. We initially added these to make it easier to check for bugs in encodings with the spec, but this is no longer relevant now that the encodings are finalised.


================
Comment at: test/MC/AArch64/SVE/assembler_tests/add.s:5
+// CHECK: add     z31.s, z31.s, z31.s // encoding: [0xff,0x03,0xbf,0x04]
+// CHECK-ERROR: {{(unexpected token in argument list)|(invalid operand for instruction)|(invalid sve vector register)|(unexpected floating point literal)|(expected ']' in brackets expression)|(instruction requires: sve)|(vector register expected)|(immediate must be an integer in range \[-128, 127\] or a multiple of 256 in range \[-32768, 32512\])}}
+// CHECK-ERROR-NEXT: 00000100-10111111-00000011-11111111
----------------
asb wrote:
> Is this really better than just matching the specific error message? If one of the messages in this list changes in the future, you either have churn across every CHECK-ERROR line in the SVE test cases, or else the CHECK-ERROR lines aren't all updated and you're left with outdated checks. You might also want to know if the error message for a given line changes between one of these unexpectedly.
> 
> Of course if FileCheck let you assign a pattern to a variable and reuse it, the trade-off would be different...
One of the things I forgot to mention is that these tests are all auto-generated from our architecture spec. If one of the error messages changes, we can update the generator and create a new set of tests. Even if we had more specific messages, I think we still have to update quite a bunch of tests anyway, but I agree with you that testing for a specific error message makes more sense (and indeed we could pick up on changes between the checked error messages). When we did the assembler/disassembler work, it covered the cases well enough.

That said, I'm happy to make changes to the tests. It is actually a good topic to get feedback on, and we don't necessarily need to stick with the auto-generated approach.

For now though I would rather collect some more input on how the tests should look before making the changes in each patch individually, for the following reasons:
1. If there are some 'batch' changes we want to make, we can easily regenerate the tests.
2. I have currently split up the assembler/disassembler into many, many small patches, including tests. If I would re-generate the tests now, I'd need to fix each patch individually which is a pain :)

When we agree how we want the tests to look and most of the patches are in, I can easily create patches for the tests alone. Does that approach make sense?


================
Comment at: test/MC/AArch64/SVE/disassembler_tests/add.s:5
+# CHECK: add     z31.s, z31.s, z31.s // encoding: [0xff,0x03,0xbf,0x04]
+# CHECK-ERROR-NOT: add     z31.s, z31.s, z31.s 
+0xb7,0x01,0xe8,0x04
----------------
asb wrote:
> Would it not be better to check that llvm-mc -disassemble -mattr=-sve results in an unknown instruction, rather than "_anything_ other than the specific SVE instruction".
> 
> A number of backends have found it useful to combine disassembly with assembly tests in a single file (see e.g. test/MC/RISCV/rv32i-valid.s), and I think you might benefit from a similar "round-trip" testing approach.
Both suggestions sound sensible to me! (although I'd like to refer to my previous comment about changing the tests now)


https://reviews.llvm.org/D39091