[PATCH] D83275: [llc] (almost) remove `--print-machineinstrs`

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 17 15:05:29 PDT 2020


arsenm added inline comments.


================
Comment at: llvm/test/CodeGen/Hexagon/ifcvt-edge-weight.ll:1
-; RUN: llc -march=hexagon -mcpu=hexagonv5 -hexagon-eif=0 -print-machineinstrs=if-converter %s -o /dev/null 2>&1 | FileCheck %s
+; RUN: llc -march=hexagon -mcpu=hexagonv5 -hexagon-eif=0 -print-after=if-converter %s -o /dev/null 2>&1 | FileCheck %s
 ; Check that the edge weights are updated correctly after if-conversion.
----------------
arsenm wrote:
> ychen wrote:
> > arsenm wrote:
> > > This test should probably be switched to stop-after and MIR
> > There is a general problem is that `-printer-after` uses `MachineFunctionPrinterPass`(MachineFunction::print) whereas `-stop-after` uses `MIRPrinter`(in MIR serialization format). The general question is could we just use only of them? thoughts? maybe `MIRPrinter` since it  *seems* the information it prints is a superset of what `MachineFunction::print` prints.
> > 
> > For this particular test, I could use `stop-after` because the check lines are simple. For the next two, using `stop-after` makes the tests fail. How about I add FIXME instead?
> Yes, the output of the machine debug dumps and MIR dumps are slightly different. They're gradually converging. Eventually we should probably only have the MIR dumps, with some simplifications for debug printing cases (e.g. prune some of the function metadata in the common cases)
> 
> I think there's no legitimate reason for a test to be scraping the machine debug dumps when it could be checking the MIR instead. 
Why do they fail? The "After.." checks can just be deleted.

There may may be a complication for the DBG_VALUE, I think there are some issues with serialization of debug info in MIR still


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83275





More information about the llvm-commits mailing list