<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">We (Intel) use opt-bisect most often in conjunction with clang and frequently with applications that have non-trivial compilation mechanisms. If there isn’t a
way to get something hooked up through code generation, it doesn’t really meet the needs of the way we are using it. As an interim solution it would be tolerable to have two separate bisect-like options, one that works its way through the pre-codegen passes
and a different one that bisects codegen.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Skipping “necessary” passes is a somewhat different matter, because you can’t skip something like register allocation on your way to executable code. Most of
the passes that are really significant in this way are codegen passes, so we might still be able to work something out. I believe there are a few pre-codegen passes that are required but they do trivial things like removing intrinsics that don’t get lowered.
Perhaps we could have some mechanism that builds a set of clean up passes that get run under some very limited circumstances. Is that what you were suggesting in your comment about running “some minimal second set of passes” after the bisection?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The current opt-bisect mechanism really doesn’t do much more than increment a counter, but it does produce output that indicates what was run and what wasn’t.
This is very useful for finding the proper owner for a bug once the failure has been diagnosed with opt-bisect. I don’t really care how the mechanism is implemented, but I’d really like to know what the last optimization was that ran in a failing case and
which IR unit it was run on. Knowing the highest pass count that was used is also helpful to establish a starting point.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Chandler Carruth [mailto:chandlerc@gmail.com]
<br>
<b>Sent:</b> Thursday, October 04, 2018 12:59 AM<br>
<b>To:</b> Fedor Sergeev <fedor.sergeev@azul.com><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org>; Zhizhou Yang <zhizhouy@google.com>; David Greene <dag@cray.com>; David Blaikie <dblaikie@gmail.com>; Kaylor, Andrew <andrew.kaylor@intel.com>; Chandler Carruth <chandlerc@gmail.com><br>
<b>Subject:</b> Re: [llvm-dev] OptBisect implementation for new pass manager<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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....<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Some immediate simplifications:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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)?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Hope all of this makes some sense.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-Chandler<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Sep 26, 2018 at 9:54 AM Fedor Sergeev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>