search for: passinstrumentation

...osal ======== 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) PassMan...

...ood reference point for "compilation-local singleton stuff". My task is to provide a way to handle callbacks per-compilation-context, and preferably have a single copy of those (possibly stateful) callbacks per compilation. In my implementation (linked at the end of RFC) I'm using PassInstrumentationImpl to have a single copy of object. What entity should *own* PassInstrumentationImpl object to make it unique per-compilation? Again, in my implementation with Analysis-managed PassInstrumentation I put Impl into PassBuilder which registers Analyses with a reference to its Impl. However that ma...

...posal ======== 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) PassMana...

...- 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() >>...

...ere 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 tra...

Hello Fedor. Thank you for the information. I made a simple patch that exposes PassInstrumentationCallback so llvmGetPassPluginInfo can use it: https://reviews.llvm.org/D71086 . Would this change make sense? Thanks, Juneyoung Lee On Thu, Dec 12, 2019 at 12:44 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 12/3/19 8:01 PM, Juneyoung Lee via llvm-dev wrote: > &gt...

Hello all, Is there a way to register callback that runs before/after passes? PassTimingInfo seems to do a similar thing by calling PassInstrumentationCallbacks::registerBeforePassCallback / registerAfterPassCallback, but it is hard-wired with StandardInstrumentations class. Do we have something similar to RegisterStandardPasses, so custom callbacks can be added from somewhere outside LLVM? Thanks, Juneyoung Lee -------------- next part ---------...

...is a known layering issue > >    - Pass hierarchy provides skipModule etc helper functions > >    - Individual passes opt-in to OptBisect activities by manually > calling skip* helper functions >      whenever appropriate > > With current state of new-pm PassInstrumentation potential OptBisect > implementation > will have the following properties/issues: >    - OptBisect object that exists per compilation pipeline, managed > similar to PassBuilder/PassManagers >      (which makes it more suitable for use in parallel compilations) &gt...

...And we are completely in control of how we do the PassRegistry.def registration. At run-time we have a bunch of objects involved into the registration:   PassBuilder   OptBisect   pass object to be registered We can make their interaction to be as complex as needed. Say, it is easy to extend PassInstrumentation interface to cover the registration time and have PassBuilder invoke corresponding instrumentations, leading to OptBisect being able to act upon a pass registration. Similarly, PassBuilder can pass control to the pass object and have it discover that OptBisect is in action. > I brought up sch...

...argets to customized, inlining opportunity and fits the overall NPM value semantics design. There are potential compile-time issues, but I don't think it is a major concern at this moment. The design is not intrusive to make a change inhibitive. `class TargetPassConfig`(2) is implemented using PassInstrumentation as much as possible because PassInstrumentation is commonly used for debugging features already. This makes `class CodeGenPassBuilder` only do what it is supposed to do. PassInstrumentation is also more flexible than inserting debugging passes into the pipeline. `class TargetPassConfig`(3) is part...

...is defined in lib/IR, but does use analyses,     which is a known layering issue   - Pass hierarchy provides skipModule etc helper functions   - Individual passes opt-in to OptBisect activities by manually calling skip* helper functions     whenever appropriate With current state of new-pm PassInstrumentation potential OptBisect implementation will have the following properties/issues:   - OptBisect object that exists per compilation pipeline, managed similar to PassBuilder/PassManagers     (which makes it more suitable for use in parallel compilations)   - no more layering issues imposed by imple...

Fedor Sergeev <fedor.sergeev at azul.com> writes: > On 06/12/2018 12:04 AM, David A. Greene wrote: >> // PIA - PassInstrumentationAnalysis >> if (PIA->skipTransformation()) { >> return; >> } >> // Do it. >> PIA->didTransformation(); > That should be easily doable (though the interface would be part of > PassInstrumentation > rather than PassInstrumentationAnalysis). Ok. The wa...

Looking through some of the remaining test failures under the new pass manager, I've narrowed down one of the failures in GWPAsan(!) to the fact that the new pass manager doesn't properly skip passes like the old pass manager. For example, when a function is marked optnone, or when using https://llvm.org/docs/OptBisect.html. Lots of passes (e.g. SROA) will do the following under the

...ses, > which is a known layering issue > > - Pass hierarchy provides skipModule etc helper functions > > - Individual passes opt-in to OptBisect activities by manually calling > skip* helper functions > whenever appropriate > > With current state of new-pm PassInstrumentation potential OptBisect > implementation will have the following properties/issues: > - OptBisect object that exists per compilation pipeline, managed > similar to PassBuilder/PassManagers > (which makes it more suitable for use in parallel compilations) > > - no more layer...

...is a known layering issue > >    - Pass hierarchy provides skipModule etc helper functions > >    - Individual passes opt-in to OptBisect activities by manually > calling skip* helper functions >      whenever appropriate > > With current state of new-pm PassInstrumentation potential > OptBisect implementation will have the following properties/issues: >    - OptBisect object that exists per compilation pipeline, > managed similar to PassBuilder/PassManagers >      (which makes it more suitable for use in parallel compilations) > >...