[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#3103632 <https://reviews.llvm.org/D113030#3103632>, @qcolombet wrote:

> Hi Amara,
>
> I am kind of repeating what I said in https://reviews.llvm.org/D113031, but putting it here for better visibility.
>
> I think the thing that drives the bisection shouldn't trickle down in the optimizations themselves, instead I would rather this information to be encoded in the IR itself (like a generalization of `optnone`).
>
> For instance, for us a daemon based approach doesn't work at all because we are running a JIT compiler that runs in its own sandbox and we cannot query an external process from it.
>
> Internally, we developed a bisect tool that annotates the IR upfront (to make an analogy with clang, this is as if clang would add a bunch of "bisect" attribute on the IR) before sending it for compilation instead of having the backend query a bisection client.
> Note: technically we didn't modify clang, we instead had a specific pass at the beginning of the LLVM pipeline that would make all the bisection decisions, but also perform some transformation to isolate the bugs (like creating functions out of basic blocks, splitting the blocks to make the functions smaller, and blocking inlining.)
>
> Cheers,
> -Quentin

How does that work when you have parallel builds? When multiple clang processes are running simultaneously, and you want to bisect to a specific translation unit, and then within that TU to a specific point in the module, don't you need some co-ordination?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113030