[llvm-dev] RFC: Pass Execution Instrumentation interface
Fedor Sergeev via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 8 00:10:22 PDT 2018
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.
On Fri, Jun 8, 2018 at 9:12 AM +0300, "Zhizhou Yang" <zhizhouy at google.com<mailto:zhizhouy at google.com>> wrote:
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?
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:
This RFC suggests an API to enable customizable instrumentation of pass
The intent is to have a common machinery to implement all the
features mentioned here.
Prime target of the interface is the new pass manager.
The overall approach and most of the implementation details should be
to the legacy one though.
There are quite a few important debugging facilities in LLVM that affect
pass execution sequence:
execute IR-print pass before or after a particularly
(or all passes)
execute verifier pass after each
execute passes only up to a selected "pass-counter"
track execution time for each pass
There are also quite a few similar ideas floating around, i.e:
All these facilities essentially require instrumentation of pass
in the pass manager, each being implemented in a legacy pass manager
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
which obviously is a problem for new pass manager transition.
- 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
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)
this analysis and run instrumentation call specific to a
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.
certain unique identifier for a pass (pass name?).
a number that uniquely identifies this particular pass
in current pipeline, as tracked by Pass Manager.
Run at the start/end of a pass pipeline execution.
(useful for initialization/finalization purposes)
3. custom callbacks are registered with
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.
- 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
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).
- whats the best way to handle ownership of PassInstrumentation
Any problems with owning by LLVMContext?
Something similar to TargetLibraryInfo (owned by
- 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
PassInstrumentationAnalysis proof-of-concept unfinished prototype
(Heavily under construction, do not enter without wearing a hard hat...)
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev