[PATCH] D88200: [llvm-dwarfdump][test] Rewrite verify_die_ranges.s in YAML. NFC.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 25 11:16:22 PDT 2020


dblaikie added inline comments.


================
Comment at: llvm/test/tools/llvm-dwarfdump/X86/verify_die_ranges.yaml:1
+# RUN: yaml2obj %s | not llvm-dwarfdump -verify - | FileCheck %s
+
----------------
jhenderson wrote:
> dblaikie wrote:
> > jhenderson wrote:
> > > Whilst you're modifying this test, I'd split this up into separate yaml2obj and llvm-dwarfdump commands (i.e. no piping between the two) to make it easier to debug the test in the future.
> > FWIW, I tend to find the single command line easier to debug - don't have to worry about whether a test case has written a certain output file or not, etc. I can take the whole command line and know it's standalone/accounts for everything needed. (so if I rebuild llc I don't then have to go and dig up the applicable llc command, etc)
> When I find a failing test using the single-command line, and want to run the middle command, I can't precisely because the input file doesn't exist, meaning I have to modify the test before debugging it. In addition, I already have the full command-line from the lit -v output that I need to rerun the bit I'm interested in.
Yeah, there's some awkwardness either way, for sure.

Often times I want to iterate on changing the product code - so having it all in one command line makes it easy to rerun - when I forget this and copy/paste only the dump+filecheck line from the test, then modify the product code and rerun the test only to see no improvement it can take me a moment to realize what's happened.

Rerunning the whole test might not be ideal either, if it now passes (or fails earlier), running some other test variant that overwrites the desired input file.

Also the failure tends to be more clear to me - I can copy/paste the whole command line and know I've captured everything I need to repeatedly exercise the codepath/test, not relying on some leftover artifact of the test's previous execution.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88200/new/

https://reviews.llvm.org/D88200



More information about the llvm-commits mailing list