search for: optbisect

...me information (such as the > target) during pass registration. The registration logic is for sure baked into the sources :) 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 registra...

Hi Chandler, I am now working on a bisecting tool to find mis-optimization on LLVM. I found OptBisect a very useful option and hope to make it work on the new pass manager. I have several questions about it. 1. Any plans to apply codegen stage with new pass manager? IIUC, new pass manager only works for opt stage. However the OptBisect option tries to accumulate pass counts through opt stage a...

.../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 bases its decisions on information provided by passes/pass managers, it still has a final say. So, whenever we choose opt-in or opt-out, it should happen either in OptBisect entirely, or coordinated between passes/pa...

...s like our current vocabulary is somewhat imprecise. I'm not sure that I fully gather which part of pipeline construction/execution and which object interaction do you mean when talking about "query hooks" or "run the pass". Right now we have the following objects:    - OptBisect, which is pass-instrumentation object    - PassBuilder object that constructs the pipeline    - PassManager object that controls the pass execution    - Pass object, which is being constructed for PassBuilder and then executed with PassManager At construction time there are:   Pass, OptBisect...

....com> Cc: Kaylor, Andrew <andrew.kaylor at intel.com>; Philip Pfaffe <philip.pfaffe at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; zhizhouy at google.com; David Blaikie <dblaikie at gmail.com>; Chandler Carruth <chandlerc at gmail.com> Subject: Re: [llvm-dev] OptBisect implementation for new pass manager Fedor Sergeev <fedor.sergeev at azul.com> writes: > I don’t have strong feelings about how this happens. Off the cuff, > it could be added to the pass registration information or it could > be a function provided by the pass, preferab...

Andrew, I would not make the caller pass the description of the IR unit. That is because it would result in the description generated every time even if OptBisect is disabled. Description generation is not very chip. Thinking on the OptBisect extension, I believe passing the units are the right choice because OptPassGates may use them to make pass skipping decisions. -Yevgeny Rouban ----------------------------------------------------------- *From:* llvm-d...

So... looking at OptBisect, I have a few thoughts: 1) what's the purpose of the virtual interface/OptPassGate? I'm guessing maybe that worked around the circular referencing in these APIs? hmm, no, I suppose that wouldn't work/be relevant here. 2) Why is OptBisector a ManagedStatic? That seems pretty antithetic...

...y implementation is most likely not a perfect way forward. Now is a chance to take a fresh look at the overall approach and perhaps do better, without the restrictions that legacy pass manager framework imposed on the implementation. Kind of a summary of what we have now:   - There is a single OptBisect object, requested through LLVMContext     (managed as ManagedStatic).   - OptBisect 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...

...hat were added with no awareness of > opt-bisect would be automatically included. However, there is a small > wrinkle to this. I can't defend this as a reasonable design choice, but the > SelectionDAGISel pass has a sort of hybrid behavior. It can't actually be > skipped, but it OptBisect says it should be skipped it drops the > optimization level to OptNone. That's a machine function pass, so it > doesn't matter so much right now. It's just something to think about. > > One of the reasons that we combined the optnone handling and the > opt-bisect handling...

...s a chance to take a fresh look at the overall > approach and perhaps > do better, without the restrictions that legacy pass manager > framework > imposed on > the implementation. > > Kind of a summary of what we have now: >    - There is a single OptBisect object, requested through LLVMContext >      (managed as ManagedStatic). > >    - OptBisect is defined in lib/IR, but does use analyses, >      which is a known layering issue > >    - Pass hierarchy provides skipModule etc helper functions > >    - Indiv...

...code that as an overrideable default, such as by tracking a >> list of non-skippable passes right there in the implementation. > I think that's compeletely fine. You're right that neither the pass > manager nor the pass can make those decisions. Yes, I believe we can state that OptBisect (and OptBisect only) makes those decisions. > The piece I don't yet > grasp is how we express that a pass is not skippable (or may be run in > degraded mode) in various contexts. How do we provide the information > so that pass instrumentation may make the correct decision? As...

& 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 i...

So I'm poking around trying to improve the layering of LLVM (using an internal strict modular build as a motivation/tool to identify issues) & came across a layering violation in the OptBisect implementation. This feature is implemented in lib/IR, but includes several headers from include/llvm/Analysis - which would create a circular dependency if not for the fact that all the headers it includes are header-only (templates). Any ideas about how this could/should be fixed? Perhaps these...

...#39;m not sure that I fully gather which part of pipeline > > construction/execution and which > > object interaction do you mean when talking about "query hooks" or > > "run the pass". > > > > Right now we have the following objects: > > - OptBisect, which is pass-instrumentation object > > - PassBuilder object that constructs the pipeline > > - PassManager object that controls the pass execution > > - Pass object, which is being constructed for PassBuilder and then > > executed with PassManager > > >...

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 management issue. It is left for the discretion of passgate object provider. > > If that becomes the /only/ option (ie: LLVMContext has no default OptPassGate) then the vi...

...ah, I'm interested to continue this design discussion, although my > interests > are primarily in the area of new pass manager currently. > I'm going to post a separate RFC on that topic. > Sounds good. Looping back for this thing - would it be reasonable to remove the default OptBisect from IR, move it into Transform or some other leafier dependency? Leaving only the basic interface (that can get away with forward declarations of Region, Loop, etc) in IR? Is that likely to be done in the patch under review, or shortly after it? > > regards, > Fedor. > > On 04/...

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 management issue. > It is left for the discretion of passgate object provider. > > > > > If that becomes the /only/ option (ie: LLVMContext has no defau...

...al Analysis, it definitely will be able to address this layering issue (as a side-effect :). I very much hope to be able send something real to the list in less than a week. regards,   Fedor. On 04/24/2018 01:42 AM, David Blaikie wrote: > 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 > <mailto:dblaikie at gmail.com>> wrot...

...gree that whether or not the new PM becomes default is somewhat orthogonal but eventually it will and at that point I hope we have a functioning opt-bisect for codegen. -David Fedor Sergeev <fedor.sergeev at azul.com> writes: > I would really like to separate OptBisect and New-PM-by-default > discussions! :) > > regards, >   Fedor. > > On 09/26/2018 09:13 PM, David Greene wrote: >> I'm concerned about codegen. If Codegen is not yet ready for the new >> PM, should the new PM really become default? I would at least like to >&g...

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 a...