[PATCH] D128470: llvm-reduce: reduce using opt passes

[John Regehr via Phabricator via llvm-commits]

regehr created this revision.
regehr added reviewers: aeubanks, fhahn.
Herald added subscribers: jdoerfert, mgorny.
Herald added a project: All.
regehr requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This patch teaches llvm-reduce to run opt passes. The rationale for this comes in three parts:

1. opt passes have the potential to usefully shrink test cases in ways that are more powerful than the existing delta passes that we have. for example, SROA cleans up a lot of allocas, InstCombine does lots of other simplifications, etc.
2. running opt passes can bring the test case closer to the actual input that gets miscompiled. consider an example where we're reducing some unoptimized IR that gets miscompiled 25 passes into the phase ordering. by running some of these earlier passes, we make the test case into something that is more directly miscompiled, making it easier to understand what's going on and also making it easier to tell if the bug trigger is a duplicate.
3. opt passes try to canonicalize the code, and we like canonicalization because for those of us who read a lot of canonical IR it's easier to understand. if there are non-canonical aspects to our test case that are inessential for triggering a bug, we should eliminate them.

A drawback of this patch is that it makes llvm-reduce run slower -- on my machine, this patch makes my machine take 2.4 seconds instead of 1.6 seconds to run all of the llvm-reduce test cases. The other drawback that I can think of is that if we're trying to reduce a file that crashes one of the passes we're trying to run, llvm-reduce will also crash (I have a solution to this, but was hoping to land this patch first).

One thing to discuss is the set of passes that we run here, I've just gone and picked some by hand that seem like they are mostly going to simplify the code, but am open to discussion about which passes make the most sense.

Another thing we could discuss is when to run the opt passes. Here I have them running right at the beginning, when there should be lots of opportunities for them to clean things up, but we could also make an argument for running them at the end of the llvm-reduce phase ordering so that they'll canonicalize the IR as much as possible before it gets dumped out for human consumption.


https://reviews.llvm.org/D128470

Files:
  llvm/test/tools/llvm-reduce/reduce-using-passes.ll
  llvm/test/tools/llvm-reduce/remove-attributes-from-intrinsic-like-functions.ll
  llvm/test/tools/llvm-reduce/remove-attributes-from-intrinsics.ll
  llvm/test/tools/llvm-reduce/remove-function-bodies-used-in-globals.ll
  llvm/test/tools/llvm-reduce/remove-invoked-functions.ll
  llvm/test/tools/llvm-reduce/remove-operands-fp.ll
  llvm/test/tools/llvm-reduce/remove-operands.ll
  llvm/tools/llvm-reduce/CMakeLists.txt
  llvm/tools/llvm-reduce/DeltaManager.cpp
  llvm/tools/llvm-reduce/deltas/ReduceUsingOpt.cpp
  llvm/tools/llvm-reduce/deltas/ReduceUsingOpt.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D128470.439541.patch
Type: text/x-patch
Size: 15303 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220623/ba264369/attachment.bin>