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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D113030#3103971 <https://reviews.llvm.org/D113030#3103971>, @aemerson wrote:

> In D113030#3103903 <https://reviews.llvm.org/D113030#3103903>, @lebedev.ri wrote:
>
>> I would like to note that there's some rudimentary support
>> for previous generation of this scattered throught the codebase,
>> namely DebugCounters for bugpoint.
>>
>> I don't really have an opinion on the proposal at large,
>> but i think it may be important to not just introduce a yet another variant
>> of dealing with the same issue, but only have a single good modern way.
>
> Yes, I've seen DebugCounter. It's useful when you're already identified the file where something is going wrong, and you can enable the counters and pass counter values to opt. It doesn't however work across multiple TUs or support parallel debugging, so it's not solving the same problem.

Perhaps it'd be worth considering the overlap here, and maybe avoiding it: What would it be like if this new thing /only/ bisected at the granularity of a whole compilation action (ie: one invocation of clang), rather than specific optimizations? (possibly even only at the "whole compiler" granularity - using two compilers - and choosing between one or the other for each compilation)

Then once the specific file has been identified, use the existing sub-file granularity tools (a wrapper script could help cover both of these for the user so it wasn't a bunch more manual work).

I think that might help prevent overlap of functionality/re-implementing similar/the same functionality through different mechanisms for reducing specific optimization applications?

(also: probably an add-on for the future: Have you considered not requiring a clean build for each bisection step? Would it be feasible to have the bisect tool delete (or produce insturctions the user can copy/paste, if preferred) specific output files it knows it's going to change - then letting the user rerun an incremental build that will cause those files to be regenerated and allowing the bisect tool to intercept their building to adjust how they're built - it seems like this only requires a reliable build system (so it could be optional, so it could be turned off in cases where a build system doesn't reliably check for existing outputs) and could significantly improve performance of such a tool?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113030