The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
Previously, bug reducer tester would just assert when it saw a direct apply to
its target function. Now we add support for also causing a miscompile by just
deleting the apply. This is tested by eliminating an apply to putchar to ensure
we are not dependent on any stdlib details.
That would be incorrect in the case where the bug reducer did not crash on the
last iteration. I ran into this a few weeks ago when using the random bug
finder, but can not seem to reproduce the issue.
I would rather fix it than have someone hit this.
Now once you have a pass list using:
./bug-reducer opt ...
You can take the pass list and give it and the output file to bug-reducer func:
./bug-reducer func ...
which will reduce the function list for you given a pass list. This is kept
separate to allow for testing and orthogonality. In a future commit, I am going
to add an option to ./bug-reducer opt that will invoke the function reducer
automagically.
This enables us to specify variables like module_name, sdk without having the
SILToolInvoker rely on the argument for the input_file. This is a nice
separation and will let me implement easily a func_bug_reducer tool that can be
enabled after reducing the number of functions using opt_bug_reducer.py.
Originally I put this distinction in to ensure that we matched the pass pipeline
more exactly since the early module passes run until fix point. This upon
further reflection actually should not cause any issues given the bottom up pass
manager. So just treat the early module passes as normal passes, simplifying the
bug reducer.
Currently it supports random bug finding and opt pipeline reduction. At some
point in the future it will support:
1. Reducing of optimizer crasher test cases.
2. Reducing optimizer miscompile test cases.
But those are for another time, this is just a first step. Patches welcome = ).
Check out llvm's bugpoint for inspiration.
It also has a basic test of pass pipeline reduction that is triggered via the
validation testing in lit. One thing to note here is that the tool right now
assumes darwin. This can be fixed in the future.
