This is an archive of the discontinued LLVM Phabricator instance.

[ARM][AArch64] Test case debugging output
AbandonedPublic

Authored by MarkMurrayARM on Dec 15 2020, 1:10 AM.

Details

Reviewers
None
Summary

Add extra output for the mismatch cases to show where bitmap
mismatches are ocurring.

Diff Detail

Event Timeline

MarkMurrayARM created this revision.Dec 15 2020, 1:10 AM
MarkMurrayARM requested review of this revision.Dec 15 2020, 1:10 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 15 2020, 1:10 AM
DavidSpickett added a subscriber: DavidSpickett.EditedDec 15 2020, 2:03 AM

I see the idea to give some immediate improvement but I think there's more to be done to inform the user properly:

  • Convert all of the runs of ASSERT_TRUE to individual tests using a test fixture (or two), for example [0]
  • Creating a custom assertion message that includes the CPU name and the feature [1]
  • Treating the features as a set, so we can say in one go "the features <list> are missing", instead of a one by one check
  • Printing feature names when we do find a missing bit, you an ask the target parser for that

But I get that that's more than you bargained for.

I think the messages as they stand only help local development, where you know what you broke because you're adding a CPU.
If I'm working on seemingly unrelated code, I don't see how these messages give me any more info than the single gtest failure we have now.

Like ok the ARM cpus test failed on this bit. Ok. What does that mean?

Also I'm not a fan of random errs messages in buildbot logs but that's mostly my preference. I don't think there's a rule for it.

You could add context to these errs messages but still I'm not a fan of errs as a mechanism for reporting this. That's what failure messages are for.

[0] https://github.com/llvm/llvm-project/blob/32541685b2a980290c320adb289b56395a88d4c3/lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp
[1] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#using-a-predicate-formatter

Also the commit msg " Test case debugging output" should include which test cases, "target parser test cases" would do fine.

Target parser is nominally my area so if you don't have the time to pursue this (these tests don't fail often at all, so I get it) I can have a go at doing what I proposed. Then you can review for me. After all, you're the one adding the CPUs these days so you're seeing the failures.

@DavidSpickett, I would very much appreciate you taking this over, thanks! I needed a way of find out *how* these tests were failing, not just *that* they were failing. I will abandon this change.

MarkMurrayARM abandoned this revision.Dec 15 2020, 3:49 AM

No problem, I'll have something for review in a few days.