<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 06/08/2018 08:36 PM, Zhizhou Yang wrote:<br>
<blockquote type="cite"
cite="mid:CADePUz9=RbKF+SQe_BZYHKrqBk+8jwAE_hnqobyRxzbgSmZSgw@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Thanks Craig, that's exactly what I mean, stopping
at particular changes inside a pass.</div>
</blockquote>
PassInstrumentation at its current base design only instruments Pass
execution from a caller (PM) side.<br>
Stopping at a particular change inside a pass definitely requires
pass commitment and is out of scope<br>
for this RFC.<br>
<br>
Yet it appears to be rather orthogonal and I dont see anything that
precludes from enhancing PassInstrumentationAnalysis<br>
to also cover points other than those in-PMs. For sure,
PassInstrumentationAnalysis should readily be available<br>
inside the pass through the AnalysisManager.<br>
<br>
regards,<br>
Fedor.<br>
<blockquote type="cite"
cite="mid:CADePUz9=RbKF+SQe_BZYHKrqBk+8jwAE_hnqobyRxzbgSmZSgw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Would you please refer me the discuss about combining
opt-bisect with debug counters? Is it already under
implementation?</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jun 8, 2018 at 12:19 AM Craig Topper <<a
href="mailto:craig.topper@gmail.com" target="_blank"
moz-do-not-send="true">craig.topper@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I think that "level" was referring to what
level of granularity the opt-bisect should control it wasn't
mean to be read as "optimization level". I think <span
style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Zhizhou
was saying that it should be able to disable individual
optimization steps within a pass. Like if a particular run
of InstCombine made 20 changes, opt-bisect should be able
to skip each of those changes. </span>I think this is the
combining opt-bisect with debug counters idea that's been
mentioned previously.
<div>
<div><br>
</div>
<div>
<div>
<div dir="ltr"
class="m_3415741886497136881m_-9206964985855654815gmail_signature"
data-smartmail="gmail_signature">~Craig</div>
</div>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jun 8, 2018 at 12:10 AM Fedor Sergeev
via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" 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">
<div>
<div dir="auto"
style="direction:ltr;margin:0;padding:0;font-family:sans-serif;font-size:11pt;color:black">Care
to expand a bit on what you mean by per-optimization
level? Preferably with a use case.<br>
</div>
<div dir="auto"
style="direction:ltr;margin:0;padding:0;font-family:sans-serif;font-size:11pt;color:black"><br>
</div>
<div dir="auto"
style="direction:ltr;margin:0;padding:0;font-family:sans-serif;font-size:11pt;color:black">To
me optbisect is a low level developer tool and it
doesn't cope well with a crude user level hammer of
optimization level.<br>
<br>
</div>
<div dir="auto"
style="direction:ltr;margin:0;padding:0;font-family:sans-serif;font-size:11pt;color:black">F.
</div>
<br>
<br>
<br>
<div class="gmail_quote">On Fri, Jun 8, 2018 at 9:12 AM
+0300, "Zhizhou Yang" <span dir="ltr">
<<a href="mailto:zhizhouy@google.com"
target="_blank" moz-do-not-send="true">zhizhouy@google.com</a>></span>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="3D"ltr"">
<div dir="ltr">Hi Fedor,
<div><br>
</div>
<div>Thanks for replying my questions about
porting the OptBisecting to new PM.</div>
<div><br>
</div>
<div>This thread looks like a great improvement
on what we currently have.</div>
<div>Though we are also trying to make
opt-bisect more granular.</div>
<div><br>
</div>
<div>In particular, we think it would be helpful
if we could have opt-bisect work on a
per-optimization level rather than per-pass
level.</div>
<div>I believe this will be a more invasive
change and we would like to do this as a
follow-up to this thread.</div>
<div><br>
</div>
<div>How difficult do you think it would be to
support this use-case with your design?</div>
<div><br>
</div>
<div>Thank you!</div>
<div>Zhizhou</div>
<div> </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Jun 6, 2018 at 5:00 PM
Fedor Sergeev via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" 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">
TL;DR<br>
====<br>
<br>
This RFC suggests an API to enable
customizable instrumentation of pass <br>
execution.<br>
The intent is to have a common machinery to
implement all the <br>
pass-execution-debugging<br>
features mentioned here.<br>
<br>
Prime target of the interface is the new pass
manager.<br>
The overall approach and most of the
implementation details should be <br>
equially applicable<br>
to the legacy one though.<br>
<br>
<br>
Background<br>
==========<br>
<br>
There are quite a few important debugging
facilities in LLVM that affect<br>
pass execution sequence:<br>
<br>
-print-after/-print-before[-all]<br>
execute IR-print pass before or after
a particularly <br>
insteresting pass<br>
(or all passes)<br>
<br>
-verify-each<br>
execute verifier pass after each<br>
<br>
-opt-bisect-limit<br>
execute passes only up to a selected
"pass-counter"<br>
<br>
-time-passes<br>
track execution time for each pass<br>
<br>
There are also quite a few similar ideas
floating around, i.e:<br>
-git-commit-after-all<br>
-debugify-each<br>
<br>
All these facilities essentially require
instrumentation of pass <br>
execution points<br>
in the pass manager, each being implemented in
a legacy pass manager <br>
through their<br>
own custom way, e.g:<br>
* -time-passes has a bunch of dedicated
code in each of the pass managers<br>
<br>
* -print-before/after/verify-each insert
additional passes before/after<br>
the passes in the pipeline<br>
<br>
And there is no implementation of any of these
features for the new pass <br>
manager,<br>
which obviously is a problem for new pass
manager transition.<br>
<br>
Proposal<br>
========<br>
<br>
Main idea:<br>
- introduce an API that allows to
instrument points of pass execution<br>
- access through LLVM Context (allows to
control life-time and scope <br>
in multi-context execution)<br>
- wrap it into an analysis for easier
access from pass managers<br>
<br>
<br>
Details:<br>
1. introduce llvm::PassInstrumentation<br>
<br>
This is the main interface that handles
the customization and <br>
provides instrumentation calls<br>
<br>
- resides in IR<br>
- is accessible through
LLVMContext::getPassInstrumentation()<br>
(with context owning this object).<br>
<br>
2. every single point of Pass execution in
the (new) PassManager(s) <br>
will query<br>
this analysis and run instrumentation
call specific to a <br>
particular point.<br>
<br>
Instrumentation points:<br>
<br>
bool BeforePass (PassID,
PassExecutionCounter);<br>
void AfterPass (PassID,
PassExecutionCounter);<br>
<br>
Run before/after a particular pass
execution<br>
BeforePass instrumentation call
returns true if this <br>
execution is allowed to run.<br>
<br>
'PassID'<br>
certain unique identifier
for a pass (pass name?).<br>
<br>
'PassExecutionCounter'<br>
a number that uniquely
identifies this particular pass <br>
execution<br>
in current pipeline, as
tracked by Pass Manager.<br>
<br>
void StartPipeline()<br>
void EndPipeline()<br>
<br>
Run at the start/end of a pass
pipeline execution.<br>
(useful for
initialization/finalization purposes)<br>
<br>
<br>
3. custom callbacks are registered with <br>
PassInstrumentation::register* interfaces<br>
<br>
A sequence of registered callbacks is
called at each <br>
instrumentation point as appropriate.<br>
<br>
4. introduce llvm::ExecutionCounter to
track execution of passes<br>
<br>
(akin to DebugCounter, yet enabled in
Release mode as well?)<br>
<br>
Note: it is somewhat nontrivial to
uniquely track pass executions <br>
with counters in new pass<br>
manager as its pipeline schedule can be
dynamic. Ideas are welcome <br>
on how to efficiently<br>
implement unique execution tracking that
does not break in <br>
presence of fixed-point iteration<br>
passes like
RepeatedPass/DevirtSCCRepeatedPass<br>
<br>
Also, the intent is for execution
counters to be able provide <br>
thread-safety in multi-threaded<br>
pipeline execution (though no work
planned for it yet).<br>
<br>
5. introduce a new analysis
llvm::PassInstrumentationAnalysis<br>
<br>
This is a convenience wrapper to provide
an access to <br>
PassInstrumentation via analysis framework.<br>
If using analysis is not convenient
(?legacy) then <br>
PassInstrumentation can be queried<br>
directly from LLVMContext.<br>
<br>
<br>
Additional goals<br>
================<br>
<br>
- layering problem<br>
Currently OptBisect/OptPassGate has
layering issue - interface <br>
dependencies on all the "IR units",<br>
even those that are analyses - Loop,
CallGraphSCC.<br>
<br>
Generic PassInstrumentation facilitiy
allows to inject arbitrary <br>
call-backs in run-time,<br>
removing any compile-time interface
dependencies on internals of <br>
those callbacks,<br>
effectively solving this layering issue.<br>
<br>
- life-time/scope control for multi-context
execution<br>
<br>
Currently there are issues with
multi-context execution of, say, <br>
-time-passes which store<br>
their data in global maps.<br>
<br>
With LLVMContext owning
PassInstrumentation there should be no <br>
problem with multi-context execution<br>
(callbacks can be made owning the
instrumentation data).<br>
<br>
Open Questions<br>
==============<br>
<br>
- whats the best way to handle ownership of
PassInstrumentation<br>
<br>
Any problems with owning by LLVMContext?<br>
Something similar to TargetLibraryInfo
(owned by <br>
TargetLibraryAnalysis/TargetLibraryInfoWrapperPass)?<br>
<br>
- using PassInstrumentationAnalysis or
directly querying LLVMContext<br>
<br>
PassInstrumentationAnalysis appeared to
be a nice idea, only until <br>
I tried querying it<br>
in new pass manager framework, and amount
of hooplas to jump over <br>
makes me shiver a bit...<br>
<br>
Querying LLVMContext is plain and
straightforward, but we do not <br>
have a generic way to access LLVMContext<br>
from a PassManager template (need to
introduce generic <br>
IRUnit::getContext?)<br>
<br>
Implementation<br>
==============<br>
<br>
PassInstrumentationAnalysis proof-of-concept
unfinished prototype <br>
implementation:<br>
(Heavily under construction, do not enter
without wearing a hard hat...)<br>
<br>
<a href="https://reviews.llvm.org/D47858"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://reviews.llvm.org/D47858</a><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>
</blockquote>
</div>
</div>
_______________________________________________<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>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>