<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<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>
</body>
</html>