<div dir="ltr">Thanks Craig, that's exactly what I mean, stopping at particular changes inside a pass.<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">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">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">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">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">https://reviews.llvm.org/D47858</a><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" rel="noreferrer" target="_blank">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">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>