That said, it's awfully painful. I wonder -- if we expect to be doing this sort of bisection on a regular basis -- maybe we should pursue the idea of optimization fuel instead? (Sorry, @camlorn, to distract you.)
The hacky version of the idea is not dissimilar, just a bit more abstract. The file is replaced by an integer. In "dump" mode, the compiler loads the integer and adds to it as it goes. In "check" mode, the compiler subtracts, and stops "optimizing" once it reaches 0. A less hacky version could be aided by cargo.
Oh, and speaking of cargo, I guess that cargo builds run in parallel? Presumably you can disable that somehow though when doing this sort of optimization.
The thing I like about the "fuel" approach is that we could re-use it for other such optimizations in the future (i.e., you have the same fuel infrastructure, but you apply it to different tasks). But probably we could use an expanded variant of the def-path strings (i.e.,
Optimization(DefPath)) and those don't have the "parallel build" problem.
I'm certainly sorry that this is such a pain. =( I feel like it's an awesome tool for us to have, though -- this kind of thing makes all the difference when you're staring down some kind of crazy crash, no? In my ideal world, we'd have it not only for struct reorderings but for more and more sorts of optimizations (which is why I got to wondering about fuel). I think all in all this would make a good topic of discussion for the "compiler design sprint" that just happens to be going on today. =)