<div dir="ltr"><div dir="ltr">I read this tool and I believe this could do a perfect job as a general bisecting script using DebugCounter.<div><br></div><div>Just one small nit that I noticed that you are using (1<<32) as a default upper bound. I have a patch that</div><div>could print the total number of transformations in a single pass: <a href="https://reviews.llvm.org/D50031">https://reviews.llvm.org/D50031</a>. I think it</div><div>may be helpful to let the user know exactly how many transformations are there in the pass, so that they</div><div>could have a high level idea of the position of bad transformation.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 20, 2018 at 9:56 AM David Greene <<a href="mailto:dag@cray.com">dag@cray.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Zhizhou Yang via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
> To bring it to the next level, DebugCounter provides features for me<br>
> to have an in-pass (transformation) level limit to tell which<br>
> transform in the pass exactly caused the error. When we set StopAfter<br>
> value for a DebugCounter, it will eventually stop there as a limit. <br>
><br>
> And in D50031 and rL337748, I added a method to print DebugCounter<br>
> info: the `-print-debug-counter` flag. With this, writing a<br>
> transformation level bisection script will be more straightforward.<br>
><br>
> I have already built a bisection tool to help Android toolchain debug<br>
> on our side. So I will say that the bisecting idea with OptBisect and<br>
> DebugCounter helps us save time while debugging mis-compilations.<br>
<br>
There is already a DebugCounter bisect tool in utils/bisect-skip-count.<br>
<br>
It is not documented, unfortunately.  I had to figure it out by<br>
inspection, but you use it by including "%(skip)d" and "$(count)d" in<br>
the command you specify to bisect-skip-count.  Then those values get<br>
filled in and your command should respond to them appropriately.  For<br>
example:<br>
<br>
bisect-skip-count bisect-command.sh "%(skip)d" "%(count)d" 2>&1 | tee bisect.out<br>
<br>
bisect-command.sh presumably looks something like this:<br>
<br>
  #!/bin/bash<br>
<br>
  skip=$1<br>
  count=$2<br>
<br>
  opt --debug-counter=my-counter-skip=${skip},my-counter-count=${count}<br>
  ...<br>
<br>
I recently used bisect-skip-count in this way very successfully to track<br>
down an aliasing bug deep in the machine scheduler.  I'm working on<br>
documenting bisect-skip-count so people know about it.  I can add<br>
comments to the script but I haven't looked at updating web page sources<br>
yet.  I was thinking of adding something to the existing opt-bisect<br>
page.  Guidance here would be helpful.<br>
<br>
I agree that anyone who adds DebugCounters should propose those changes<br>
on Phabricator.  We can incrementally improve the debuggability of LLVM<br>
with such a process.<br>
<br>
                                -David<br>
</blockquote></div>