[riggsdk]

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.