I wanted to start a discussion and see if people have ideas about where to take this tool in the nearish future. I’ll get started by listing some improvements I was thinking about contributing.
these are some overall improvements to llvm-reduce:
- I’d like to add a command line option that causes us to do the transformation part of the delta loop in a sub-process, so if a transformation crashes (this happens and it’s super annoying) it doesn’t take out the entire llvm-reduce
- it would be nice to have some bugpoint-like reduction/attribution for arbitrary middle-end pipelines
- it might be cool to optimize the order in which the reduction passes execute, though I think the ordering is pretty decent already
- let’s keep removing crashes and places where we create invalid IR. we should add
--abort-on-invalid-reductionto all test cases and perhaps do some focused testing where we run each individual pass on full-size inputs (some of the later passes live a very sheltered life in the default pipeline because earlier passes tend to do a very good job getting rid of a lot of IR)
and some enhancements to specific delta passes:
- we already call some middle-end optimizer code in a fine-grained way; for example calling InstSimplify on individual instructions and SimplifyCFG on individual basic blocks. it seems like there might be a few more passes such as SROA where we should do this.
- try to reduce switch instructions by removing individual cases, and by turning the entire switch into an unconditional branch to the default target
- try to remove nsw, nuw, and friends from instructions, expand “fast” into its sub-flags and then try to get rid of those too
- try harder to get rid of loads and stores (I don’t have specific ideas yet, other than leaning on SROA)