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