Debugging Compilers with Optimization Fuel

It seems to "just" be a compiler optimizer's version of "git bisect" to find where exactly the bug occurs in a binary search (to find the bug faster). You could in theory just linearly try enabling more and more optimization steps but that would take a very long time. Basically O(n) vs O(log n).

In laymans terms, say you've inspecting several years worth of surveillance footage to find when exactly (down to the second) when an item went missing. Starting a binary search in the video (where you answer the question at each step in the search "is the item still there") you can very quickly determine exactly when the event happened.

Same goes with optimization steps. Start compiling an app with somewhere between no or full optimization steps and continue the binary search.

The fuel appears to be how much effort the compiler spends to find optimizations. If you give it no fuel it just spits out the simplest code it can generate. If you give it fuel it will "spend" that to search for more optimal code.

Since the simplest code didn't exhibit the bug and more optimized code did they were able to bisect the fuel value to find the particular unit of fuel that caused the incorrect optimization to be run. Then they could simply diff the two runs since they were incredibly similar (ideally just that one incorrect optimization differs) which allowed them to quickly narrow down on the root cause.