<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 09/28/2018 12:25 AM, Kaylor, Andrew
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0983E6C011D2DC4188F8761B533492DE844909C2@ORSMSX115.amr.corp.intel.com">
<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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
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]-->
<div class="WordSection1"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">As
I said, that’s really outside the scope of the current
discussion except to say that the relevant question is what
component should make the decision about whether or not a pass
should be run.</span></div>
</blockquote>
A planned way of implementation for new-pm's OptBisect is for
instrumenting object to control the execution.<br>
Whenever instrumentation bases its decisions on information provided
by passes/pass managers,<br>
it still has a final say.<br>
<br>
So, whenever we choose opt-in or opt-out, it should happen either in
OptBisect entirely,<br>
or coordinated between passes/pass managers and OptBisect object.<br>
<blockquote type="cite"
cite="mid:0983E6C011D2DC4188F8761B533492DE844909C2@ORSMSX115.amr.corp.intel.com">
<div class="WordSection1"> <span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So
getting back to OptBisect, the problem is the same. What
component should decide whether or not a pass should be run?
The pass manager doesn’t know what the pass does, so it can’t
decide whether or not it can be skipped. The pass itself
should have no idea that the OptBisect process even exists. So
the pass manager needs some way of discovering whether or not
a pass can be skipped.</span></div>
</blockquote>
Pass Manager's way of discovering that is to ask the BeforePass
instrumentation.<br>
We definitely do not want to add more decision-making points into
pass manager.<br>
The question is how OptBisect object gets the information for its
decision.<br>
<br>
<blockquote type="cite"
cite="mid:0983E6C011D2DC4188F8761B533492DE844909C2@ORSMSX115.amr.corp.intel.com">
<div class="WordSection1"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I
don’t have strong feelings about how this happens. Off the
cuff, it could be added to the pass registration information
or it could be a function provided by the pass, preferably
through one of the mixins so that pass developers don’t need
to think about it.</span></p>
</div>
</blockquote>
I'm leaning towards the registration-time activities, which perhaps
means doing extra interaction between PassBuilder and OptBisect.<br>
As we seem to favor the opt-out (and for current - non-CodeGen -
implementation the out-out list appears to be empty? ) exact<br>
mechanism of that out-out does not really bother me.<br>
<br>
regards,<br>
Fedor.<br>
<br>
<blockquote type="cite"
cite="mid:0983E6C011D2DC4188F8761B533492DE844909C2@ORSMSX115.amr.corp.intel.com">
<div class="WordSection1">
<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"><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"><a name="_MailEndCompose"
moz-do-not-send="true"><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">
Philip Pfaffe [<a class="moz-txt-link-freetext" href="mailto:philip.pfaffe@gmail.com">mailto:philip.pfaffe@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, September 27, 2018 2:46 AM<br>
<b>To:</b> Kaylor, Andrew <a class="moz-txt-link-rfc2396E" href="mailto:andrew.kaylor@intel.com"><andrew.kaylor@intel.com></a><br>
<b>Cc:</b> Fedor Sergeev <a class="moz-txt-link-rfc2396E" href="mailto:fedor.sergeev@azul.com"><fedor.sergeev@azul.com></a>;
llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a>;
<a class="moz-txt-link-abbreviated" href="mailto:zhizhouy@google.com">zhizhouy@google.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:dag@cray.com">dag@cray.com</a>; David Blaikie
<a class="moz-txt-link-rfc2396E" href="mailto:dblaikie@gmail.com"><dblaikie@gmail.com></a>; Chandler Carruth
<a class="moz-txt-link-rfc2396E" href="mailto:chandlerc@gmail.com"><chandlerc@gmail.com></a><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">Hi Andrew,<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><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">We absolutely need to be able to
generate executable programs using opt-bisect, so some
mechanism for not skipping required passes is needed. It
might be nice to have a mode where no passes are skipped
and the IR/MIR is dumped when the bisect limit is
reached, but I don't see that as a requirement.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">At this point it makes no sense to
worry about the code generation pipeline. As long as
there is no new-PM design for that, this point is just
moot. Designing opt-bisect against code generation
without actually understanding what we're designing
against is guaranteed to produce a bad architecture. So
lets figure out the optimizer bisect first, and
incrementally upgrade that once we've ironed out
codegen.<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>
<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">Regarding opt-in versus opt-out, I
think we want to make this as easy and transparent to
pass developers as possible. It would be nice to have
the mechanism be opt-out so that passes that were added
with no awareness of opt-bisect would be automatically
included. However, there is a small wrinkle to this. I
can't defend this as a reasonable design choice, but the
SelectionDAGISel pass has a sort of hybrid behavior. It
can't actually be skipped, but it OptBisect says it
should be skipped it drops the optimization level to
OptNone. That's a machine function pass, so it doesn't
matter so much right now. It's just something to think
about.<br>
<br>
One of the reasons that we combined the optnone handling
and the opt-bisect handling is that we specifically
wanted these two behaviors to be linked. The exact rule
we would like to use for opt bisect is that no pass
which runs at O0 is skipped by opt-bisect. There's a
test that verifies this. Conversely, if a pass is able
to respect the optnone attribute then it should also be
skippable by opt-bisect. Of course, I would be open to
considering a use case where this reasoning isn't
desirable.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Mixing OptNone and bisect is a
software engineering bug: it's mixing different layers
of abstraction. Bisect is something that's at pass
manager scope: run passes until whatever. OptNone in
turn doesn't belong in the pass manager layer. It only
concerns function passes, and crumbles quickly
considering other IRUnits or even codegen. I don't have
a clear vision what OptNone handling should look like,
but at this point I consider it entirely orthogonal to
bisect handling.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">From a software architecture
perspective I don't see a reason why passes should even
_know_ about something like bisect happening. That is
simply not their domain. If a pass shouldn't be skipped
for whatever reason, that's not something the pass
should worry about, that's the bisect driver's problem!
My proposal here would be make it an opt-out design, but
let the driver control that. E.g., for skipping, let the
user provide a list of passes they don't want skipped.<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>
<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">With regard to there being one
OptBisect object per compilation pipeline, I have some
concerns. Specifically, the behavior of opt-bisect
depends on the sequence of passes run before the limit
is reached being consistent and repeatable. My
inclination would be to not allow parallel compilation
when opt-bisect is enabled.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">I don't have a strong opinion here,
but just as a data point: my mental model here is to
expect bisect to expect a deterministic outcome _per
module_. That model isn't threatened by parallel
execution.<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">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Philip<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <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">I can imagine cases where you might
specifically want to debug something that only happens
in a parallel build, but it's more difficult to imagine
something that only happens in a parallel build and
doesn't depend on interactions between threads. In such
a case, would we be able to guarantee that the sequence
of passes and any interaction between pipelines was
repeatable. Basically, here I feel like I'm exploring a
hypothetical idea where other people have specific use
cases. If so, please explain the use case to me.<br>
<br>
-Andy<br>
<br>
-----Original Message-----<br>
From: Fedor Sergeev [mailto:<a
href="mailto:fedor.sergeev@azul.com" target="_blank"
moz-do-not-send="true">fedor.sergeev@azul.com</a>]
<br>
Sent: Wednesday, September 26, 2018 9:54 AM<br>
To: llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>;
Zhizhou Yang <<a href="mailto:zhizhouy@google.com"
target="_blank" moz-do-not-send="true">zhizhouy@google.com</a>>;
David Greene <<a href="mailto:dag@cray.com"
target="_blank" moz-do-not-send="true">dag@cray.com</a>>;
David Blaikie <<a href="mailto:dblaikie@gmail.com"
target="_blank" moz-do-not-send="true">dblaikie@gmail.com</a>>;
Kaylor, Andrew <<a
href="mailto:andrew.kaylor@intel.com" target="_blank"
moz-do-not-send="true">andrew.kaylor@intel.com</a>>;
Chandler Carruth <<a
href="mailto:chandlerc@gmail.com" target="_blank"
moz-do-not-send="true">chandlerc@gmail.com</a>><br>
Subject: OptBisect implementation for new pass manager<br>
<br>
Greetings!<br>
<br>
As the generic Pass Instrumentation framework for new
pass manager is finally *in*, I'm glad to start the
discussion on implementation of -opt-bisect 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 likely not a perfect way forward.
Now is a chance to take a fresh look at the overall
approach and perhaps do better, without the restrictions
that legacy pass manager framework imposed on 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 calling skip* helper functions<br>
whenever appropriate<br>
<br>
With current state of new-pm PassInstrumentation
potential OptBisect implementation will have the
following properties/issues:<br>
- OptBisect object that exists per compilation
pipeline, managed 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 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 implementation that<br>
provides a sequential passes numbering through both
new-PM IR and legacy Codegen pipelines<br>
<br>
- as of right now there is no mechanism for
opt-in/opt-out, so it 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 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 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 experience that might 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"
target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>