This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by sdesmalen on Oct 19 2017, 5:05 AM.

Details

Summary

Patch [5/5] in a series to add assembler/disassembler support for AArch64 SVE unpredicated ADD/SUB instructions.

Diff Detail

Repository
rL LLVM

Event Timeline

sdesmalen created this revision.Oct 19 2017, 5:05 AM
asb added a subscriber: asb.Oct 19 2017, 6:43 AM
asb added inline comments.
test/MC/AArch64/SVE/assembler_tests/add.s
3 ↗(On Diff #119573)

I'm probably showing my ignorance here, but what's with the binary in these comments and CHECK-ERROR-NEXT?

5 ↗(On Diff #119573)

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...

test/MC/AArch64/SVE/disassembler_tests/add.s
5 ↗(On Diff #119573)

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.

sdesmalen added inline comments.Oct 19 2017, 9:33 AM
test/MC/AArch64/SVE/assembler_tests/add.s
3 ↗(On Diff #119573)

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.

5 ↗(On Diff #119573)

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?

test/MC/AArch64/SVE/disassembler_tests/add.s
5 ↗(On Diff #119573)

Both suggestions sound sensible to me! (although I'd like to refer to my previous comment about changing the tests now)

fhahn added a subscriber: fhahn.Oct 19 2017, 9:39 AM
asb added inline comments.Oct 19 2017, 6:19 PM
test/MC/AArch64/SVE/assembler_tests/add.s
5 ↗(On Diff #119573)

The only problem with auto-generated tests is that if the generator isn't publicly available it's difficult for people who don't have access to extend, refactor or otherwise improve the tests. Auto-generated tests are great, but perhaps you can make it so the test is generated in a form that's closer to how a human would write it?

Avoiding extra work for yourself while the patches are discussed certainly sounds reasonable to me!

rengolin edited edge metadata.

Adding a few AArch64 folks, to make sure we get enough eyes on this, thus avoiding silly problems in the future, if we miss anything.

This is the big one. :)

rengolin added inline comments.Oct 25 2017, 6:54 AM
lib/Target/AArch64/SVEInstrFormats.td
22 ↗(On Diff #119573)

space

test/MC/AArch64/SVE/assembler_tests/add.s
5 ↗(On Diff #119573)

I agree with both arguments from @asb here.

  1. We don't want OR in the check lines. We need to make sure we get the error we want, not *any* error, which is what we get now.
  2. Auto-generated tests are ok to create the pattern, but once the test is in, it should be human curated (or the generator has to be in LLVM's source repo, separate process).
sdesmalen updated this revision to Diff 120416.Oct 26 2017, 7:23 AM
sdesmalen marked an inline comment as done.

Updated (simplified) tests and removed whitespace.

sdesmalen added inline comments.Oct 26 2017, 7:25 AM
test/MC/AArch64/SVE/assembler_tests/add.s
5 ↗(On Diff #119573)

@rengolin I agree similarly and I don't think there is any specific need to keep the tests being auto-generated in the future (this was mostly useful when the SVE spec was still in flux and we were implementing the assembler/disassembler support. It would also be useful once more now to get the tests in a format that we want).

I've updated the tests to address the concerns like described in 1) and will look into creating a separate patch later that has a better format for the tests overall.

test/MC/AArch64/SVE/disassembler_tests/add.s
5 ↗(On Diff #119573)

I've updated these tests to check for 'invalid instruction encoding' instead.

rengolin accepted this revision.Nov 6 2017, 9:32 AM

Hi Sander,

The patch is ok to me now. I'd rather the tests were in the same file as @asb mentioned, but this can be in a following patch.

cheers,
--renato

This revision is now accepted and ready to land.Nov 6 2017, 9:32 AM

The patch is ok to me now. I'd rather the tests were in the same file as @asb mentioned, but this can be in a following patch.

Okay I'll address the test-format in one of my next patches. Thanks for your patience getting these patches in the right shape!

fhahn added a comment.Nov 7 2017, 8:48 AM

Looks good to me too. I'll commit this patch on Sander's behalf.

This revision was automatically updated to reflect the committed changes.