llvm dev - Jun 2018 - RFC: Pass Execution Instrumentation interface

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>

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>

I was going to write something up about fine-grained opt-bisect but
didn't get to it last week.

We've had a -pass-max option here for some time and have hand-added
instrumentation to various passes to honor it.  It's saved us man-years
of debug time.  I was planning on sending it upstream but saw this
effort with pass execution instrumentation and thought it might fit
there.

Initially I think some very simple APIs in PassInstrumentationAnalysis
would be fine, something like:

// PIA - PassInstrumentationAnalysis
if (PIA->skipTransformation()) {
  return;
}
// Do it.
PIA->didTransformation();

This kind of interface also encourages good pass design like doing all
the analysis for a transformation before actually doing the
transformation.  Some passes mix analysis with transformation and those
are much harder to instrument to support -pass-max operation.

In our implementation we can set a -pass-max per pass, like
-pass-max=instcombine=524.  A global index might be even more useful.
If it interacted with opt-bisect, even better.  It seems like APIs that
cover both the opt-bisect pass-level operation and the finer-grained
operation could be quite powerful.  As passes opt-in to the
finer-grained control, the opt-bisect limit would become more powerfuly
automatically.

I've always wanted a bugpoint that could point not just to a pass but to
a specific transformation within a pass.

                          -David

Fedor Sergeev via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 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> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev