<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 6/7/2019 5:19 PM, Diego Treviño via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFRRjJSz3y-Z_NzXkq7P1R1m4KMaPovqtcM3sL30St8BJR9Wng@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">### Narrow focus: test-case reduction<br>
<div>
<div>The main focus will be a code reduction strategy to
obtain much smaller test cases that still have the same
property as the original one. This will be done via classic
delta debugging and by adding some IR-specific reductions
(e.g. replacing globals, removing unused instructions, etc),
similar to what already exists, but with more in-depth
minimization.<br>
<br>
<br>
Granted, if the community differs on this proposal, the
legacy code could still be present in the tool, but with the
caveat of still being documented and designed towards delta
reduction.<br>
</div>
</div>
</div>
</blockquote>
<p>As Hal points out, there are really two dimensions of reduction
you can do with bugpoint. One is delta debugging of passes, to
figure out which pass is causing the problem, and another is
regular delta debugging of the program itself. Supporting both use
cases is important. My personal experience, however, has been to
only use bugpoint for delta debugging of code, as I'm trying to
work out what features of the input programming is causing the
pass I'm working on to crash. I can't say what the relative
balance of these two use cases are, and it may be that we can
solve this by having two versions of bugpoint to solve the two
different problems.<br>
</p>
<blockquote type="cite"
cite="mid:CAFRRjJSz3y-Z_NzXkq7P1R1m4KMaPovqtcM3sL30St8BJR9Wng@mail.gmail.com">
<div dir="ltr">
<div>
<div>### Command-Line Options<br>
We are proposing to reduce the plethora of bugpoint’s
options to just two: an interesting-ness test and the
arguments for said test, similar to other delta reduction
tools such as CReduce, Delta, and Lithium; the tool should
feel less cluttered, and there should also be no uncertainty
about how to operate it.<br>
</div>
</div>
</div>
</blockquote>
<p>I am <i>strongly</i> in favor of going to an interesting-ness
test approach in lieu of the current "try and guess what kind of
bug you're looking for" in the current approach. Writing correct
test detection scripts is definitely a challenge, but you can
usually crib from a preexisting script.</p>
<p>A second note is that we can provide much of the current
"automatic" functionality in bugpoint via a set of useful test
scripts, one for each mode.<br>
</p>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist</pre>
</body>
</html>