similar to: RFC: Pass Execution Instrumentation interface

On 06/07/2018 06:11 PM, Chandler Carruth wrote: > We had already talked about this, so unsurprisingly I'm generally in > favor of the direction. Some comments below. > > On Thu, Jun 7, 2018 at 2:00 AM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >    - access through LLVM Context (allows to control life-time and

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

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 >

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.

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

On 10/01/2018 05:01 PM, David Greene wrote: > > I think registration time is probably fine for IR/opt-level passes. For > codegen it will probably work 95% of the time but there are some cases > where we may not know at registration time whether the pass is needed or > not. I'm making the assumption that registration happens basically as > it does now, where the

Philip, It kinda depends on user expectations. What do you really expect as a result of your compilation when you set -opt-bisect-limit=X? Do you just get a resulting IR and scan for the bad pattern? Then you dont care about pass sequences and do brute-force bisect. Do you expect to get a runnable code at the end and check for buggy run-time behavior? Then you need to keep the passes that are

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: > >

On 09/28/2018 12:25 AM, Kaylor, Andrew wrote: > As I said, that’s really outside the scope of the current discussion > except to say that the relevant question is what component should make > the decision about whether or not a pass should be run. A planned way of implementation for new-pm's OptBisect is for instrumenting object to control the execution. Whenever instrumentation

Greetings! As the generic Pass Instrumentation framework for new pass manager is finally *in*, I'm glad to start the discussion on implementation of -opt-bisect through that framework. As it has already been discovered while porting other features (namely, -time-passes) blindly copying the currently existing legacy implementation is most likely not a perfect way forward. Now is a chance

Hi Andrew, We absolutely need to be able to generate executable programs using > opt-bisect, so some mechanism for not skipping required passes is needed. > It might be nice to have a mode where no passes are skipped and the IR/MIR > is dumped when the bisect limit is reached, but I don't see that as a > requirement. > At this point it makes no sense to worry about the code

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?

On Oct 16, 2008, at 8:29 AM, Edward Lee wrote: > Is there a simple way to require a pass, e.g., Reg2Mem/Mem2Reg, to > run before/after my transformation pass? Or do I do something like: One simplest way is to handle this is to add these passes around your pass in the pass manager. pm.add(Reg2Mem) pm.add(MyPass) pm.add(Mem2Reg) > > > struct myOpt { > myOpt() { >

Is there a simple way to require a pass, e.g., Reg2Mem/Mem2Reg, to run before/after my transformation pass? Or do I do something like: struct myOpt { myOpt() { mBefore = createDemoteRegisterToMemoryPass(); mAfter = createPromoteMemoryToRegisterPass(); } getAnalysisUsage(AU) { AU.addRequired(my stuff); mBefore.getAnalysisUsage(AU); mAfter.getAnalysisUsage(AU); }

David, we definitely need to address this issue and I did not forget about it. I'm still fleshing out a proposal on a generic solution for "pass execution control points", which was inspired by the new pass manager needs but then it appears we can largerly reuse the implementation for both managers. Since the implementation should be based on a special Analysis, it definitely

On Tue, Apr 3, 2018 at 8:50 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > Pass Manager (PassManager.h) itself, does not - it's only templates, > none of it depends on Region, Loop, etc. > Well, true but the problem happens when you try to instantiate the thing. > And for generic features like opt-bisection, ir-print-after-all etc that > want: > - to

On Mon, Apr 2, 2018 at 11:32 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 03/30/2018 12:05 AM, David Blaikie via llvm-dev wrote: > > & now looking back at the patch-in-progress, I see it allows setting > the OptBisector/OptPassGate as suggested in (2). > Well, the patch currently discussed does not attempt to solve the > passgate object

Ping on this - any chance we can look at fixing the OptBisect layering here/now? Could we move the implementation into Analysis & require users to set it, rather than having it as a default value in IR? On Tue, Apr 3, 2018 at 9:25 AM David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Apr 3, 2018 at 8:50 AM Fedor Sergeev <fedor.sergeev at azul.com> > wrote: >

> Pass Manager (PassManager.h) itself, does not - it's only templates, none of it depends on Region, Loop, etc. Well, true but the problem happens when you try to instantiate the thing. And for generic features like opt-bisection, ir-print-after-all etc that want:   - to have a say before/on/after every execution of every pass   - have a shared implementation of the main logic you have

& now looking back at the patch-in-progress, I see it allows setting the OptBisector/OptPassGate as suggested in (2). If that becomes the /only/ option (ie: LLVMContext has no default OptPassGate) then the virtual interface could be kept down in IR (though it's still a bit questionable to have those Analysis types (Loop, Region, CallGraphSCC) even declared in IR). Then the implementation