[PATCH] D113030: Add a new tool for parallel safe bisection, "llvm-bisectd".

[Amara Emerson via Phabricator via llvm-commits]

aemerson added a comment.

In D113030#3934444 <https://reviews.llvm.org/D113030#3934444>, @dblaikie wrote:

> In D113030#3932164 <https://reviews.llvm.org/D113030#3932164>, @arsenm wrote:
>
>> How does this differ from opt-bisect?
>
> It's cross-process/whole-build. Imagine opt-bisect, but the action tracking is for a whole build. My hope was that maybe we could do something more coarse-grained on the build level (without the need for the compiler itself to be communicating with a service) in a wrapper - eg: good/bad compiler (or flag set) and each action gets one or the other, bisect down to the fewest actions that need the bad compiler, then use opt-bisect within a single action, holding others constant, etc. So we didn't have two different ways of doing fine-grained bisection.

Right, there are two schools of thought on this. I think they're both valuable, the coarse grain wrapper approach for when you don't want to modify the compiler/want to just find a failing object file, and this one which relies on existing clients coded into the compiler.

I've been using an internal version of this tool over the past year, and it's proven invaluable in rapidly bisecting miscompiles. It was also useful to find a miscompute in the entirety of chromium, but it could do with improvements to avoid having to do an entire rebuild on each bisection step. Maybe there's a more holistic higher level design that would subsume other bisection techniques but I don't see the effort being worth it myself.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113030/new/

https://reviews.llvm.org/D113030