[llvm-dev] RFC: Pass Execution Instrumentation interface
Zhizhou Yang via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 8 10:36:18 PDT 2018
Thanks Craig, that's exactly what I mean, stopping at particular changes
inside a pass.
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> 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> 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
>> > 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> 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
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>> LLVM Developers mailing list
>> 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/899c76b7/attachment.html>
More information about the llvm-dev
mailing list