Currently, llvm-reduce runs each of its delta passes once, in a fixed order, and then exits. This is a reasonable default behavior since it allows llvm-reduce to run fairly quickly, but it fails to account for the case where a pass later in the phase ordering creates opportunities for a pass earlier in the phase ordering to make more progress.
This patch does not change the default behavior of llvm-reduce, but adds a command line parameter "max-pass-iterations" that specifies the largest number of times that the requested set of delta passes will be run. It also adds logic to bail out of the top-level reduction loop as soon as running the entire collection of passes fails to make the IR module smaller.
I have a small collection of test inputs to llvm-reduce, the average size before reduction is 15 KB. After reduction by the current llvm-reduce, the average IR file is 388 bytes. After reduction using the llvm-reduce with this proposed patch (and max-pass-iterations=10, but it always bails out earlier than that) the average reduced IR file is 250 bytes. This seems like a pretty decent win for a very simple patch, and furthermore since the default value for max-pass-iterations is 1, llvm-reduce will not be slowed down for anyone who doesn't use this new option.
I was not able to convince myself that a test for this patch would be worthwhile, instead of being fragile and silly, given the utter simplicity of the patch.
not the greatest metric, perhaps add a FIXME for a better metric?