<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/04/2018 12:58 AM, Chandler
Carruth via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGCO0Kg8tw1Z5RT6Lo36Weemod1Yw8_uPrHbq_MJXH4iHqwAzw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">Sorry I'm late to the thread (conference + vacation
delayed me). I've tried to skim the thread, but haven't found
too much real conclusions to a few points I'd like to make. If
any of the below re-hashes stuff that was already covered, my
apologies and feel free to just mention by whom or what date and
I'll read more carefully.
<div><br>
<div><br>
</div>
<div>I feel like the design of this is made unnecessarily
complex and could be simplified in a few ways. These all
stem from a key aspect of bisection: this is a *development*
activity. It doesn't have to hit some specific quality bar
the way that `optnone` and -O0 (which are both exposed to
users) need to....</div>
<div><br>
</div>
<div>Some immediate simplifications:</div>
<div><br>
</div>
<div>1) I don't think we need to go out of our way to connect
the IR pass bisection (in the new PM) with codegen's IR pass
bisection. We already have two tools (`opt` and `llc` and
can drive them separately IMO).</div>
</div>
</div>
</blockquote>
Definitely agreed.<br>
<blockquote type="cite"
cite="mid:CAGCO0Kg8tw1Z5RT6Lo36Weemod1Yw8_uPrHbq_MJXH4iHqwAzw@mail.gmail.com">
<div dir="ltr">
<div>
<div><br>
</div>
<div>2) I also don't think we need the subtle *correctness*
guarantees of `optnone` which really and truly IMO require
*passes* to make the decision rather than some abstract pass
pipeline system. </div>
<div><br>
</div>
<div>3) I think we really do want high *resolution* of
bisection even if it isn't 100% functional. Let's imagine
that this skips a "necessary" pass for some behavior. The IR
will still be valid, and this step of bisection can still be
very useful for reducing crashes and assert failures.</div>
</div>
</div>
</blockquote>
Chandler, I think you've missed a really key use case here. The
primary use case many of us have for opt-bisect is specifically
reducing miscompiles, not crashes. Compiler crashes are generally
fairly easy to reduce with bugpoint. Where we need opt-bisect is
when trying to isolate something which can't be effectively reduced
with bugpoint. Continuing to produce runnable code during reduction
is a key feature since it's the only way we can judge whether a
given transform was correct or not. <br>
<br>
My typical workflow for opt-bisect looks something like the
following:<br>
given a determinism java program whose result differs from golden
output<br>
identify which method is miscompiled by delta reducing over
compilation decisions (out of scope for opt-bisect)<br>
while (still producing wrong answer) { reduce opt-bisect limit }<br>
<br>
My point here is that I really don't think we can disregard the
notion of required passes. They're key to the use case.<br>
<br>
Your point about doing a more fine grained reduction (e.g. something
like a delta reduce over the set of transforms instead of simply a
bisection) I agree would be a very useful enhancement.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAGCO0Kg8tw1Z5RT6Lo36Weemod1Yw8_uPrHbq_MJXH4iHqwAzw@mail.gmail.com">
<div dir="ltr">
<div>
<div><br>
</div>
<div>4) I believe we can re-use the debug counter
infrastructure that did not exist when OptBisect was first
introduced rather than rolling a custom version. It's
possible there are use cases this cannot handle, but it
might be worth trying to avoid inventing another thing here.</div>
<div><br>
</div>
<div>Given the above, I'd really be interested in seeing how
far we can get with a simple debug counter wired up to the
new instrumentation framework, and nothing more. Could we
get that working? Can we see where that would be genuinely
insufficient for developers (as opposed to simply producing
a slightly different workflow or command sequence)?</div>
<div><br>
</div>
<div><br>
</div>
<div>Regarding #2 which is I think the most surprising
thing... Keep in mind that *after* we finish bisection, we
can still run some minimal second set of passes in order to
generate "correct" code. Also, I believe debug counters has
the ability to disable only for a range of counts and then
re-enable. Well designed bisection test scripts should be
able to preserve and/or synthesize the necessary bits to
keep IR "working" for whatever constraints a particular
reduction has.</div>
</div>
</div>
</blockquote>
Running a bunch of separate post processing scripts is incompatible
with my use case. It could be made to work, but only with a lot of
currently unnecessary complexity. <br>
<blockquote type="cite"
cite="mid:CAGCO0Kg8tw1Z5RT6Lo36Weemod1Yw8_uPrHbq_MJXH4iHqwAzw@mail.gmail.com">
<div dir="ltr">
<div>
<div><br>
</div>
<div><br>
</div>
<div>Hope all of this makes some sense.</div>
<div>-Chandler</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Sep 26, 2018 at 9:54 AM Fedor
Sergeev via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings!<br>
<br>
As the generic Pass Instrumentation framework for new
pass manager is <br>
finally *in*,<br>
I'm glad to start the discussion on implementation of
-opt-bisect <br>
through that framework.<br>
<br>
As it has already been discovered while porting other
features (namely, <br>
-time-passes)<br>
blindly copying the currently existing legacy
implementation is most <br>
likely not a perfect<br>
way forward. Now is a chance to take a fresh look at the
overall <br>
approach and perhaps<br>
do better, without the restrictions that legacy pass
manager framework <br>
imposed on<br>
the implementation.<br>
<br>
Kind of a summary of what we have now:<br>
- There is a single OptBisect object, requested
through LLVMContext<br>
(managed as ManagedStatic).<br>
<br>
- OptBisect is defined in lib/IR, but does use
analyses,<br>
which is a known layering issue<br>
<br>
- Pass hierarchy provides skipModule etc helper
functions<br>
<br>
- Individual passes opt-in to OptBisect activities by
manually <br>
calling skip* helper functions<br>
whenever appropriate<br>
<br>
With current state of new-pm PassInstrumentation
potential OptBisect <br>
implementation<br>
will have the following properties/issues:<br>
- OptBisect object that exists per compilation
pipeline, managed <br>
similar to PassBuilder/PassManagers<br>
(which makes it more suitable for use in parallel
compilations)<br>
<br>
- no more layering issues imposed by implementation
since <br>
instrumentations by design<br>
can live anywhere - lib/Analysis, lib/Passes etc<br>
<br>
- since Codegen is still legacy-only we will have to
make a joint <br>
implementation that<br>
provides a sequential passes numbering through both
new-PM IR and <br>
legacy Codegen pipelines<br>
<br>
- as of right now there is no mechanism for
opt-in/opt-out, so it <br>
needs to be designed/implemented<br>
Here I would like to ask:<br>
- what would be preferable - opt-in or opt-out?<br>
<br>
- with legacy implementation passes opt-in both
for bisect and <br>
attribute-optnone support at once.<br>
Do we need to follow that in new-pm
implementation?<br>
<br>
Also, I would like to ask whether people see current
user interface for <br>
opt-bisect limiting?<br>
Do we need better controls for more sophisticated
bisection?<br>
Basically I'm looking for any ideas on improving
opt-bisect user <br>
experience that might<br>
affect design approaches we take on the initial
implementation.<br>
<br>
regards,<br>
Fedor.<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>