search for: optpassgate

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

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 antithetical to the role of LLVMContext. When/why would a user be bisecting over multiple LLVMCont...

...ould 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-dev [mailto:llvm-dev-bounces at lists.llvm.org <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Kaylor, Andrew via llvm- dev *Sent:* Thursday, March 22...

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 virtual interfac...

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 default > OptPas...

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

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

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

...v 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. >> > >> > > >> > &g...

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

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

...ysis 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 comp...

...ter that can be set and if present use it instead for normal counter value check to decide if a pass should be executed or not. Or some other mechanism to provide this feature. - I am not completely sure but if we are able provide custom callback feature then we may be able to remove OptBiset and OptPassGate class. Anything missed here? Please share your thoughts. -Vivek On Thu, May 3, 2018 at 12:34 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > As a point of clarification, optnone is already being handled by the pass > itself in the legacy implementation. The skip[IR unit]...

...t;>>> 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...

...and if present use it instead for normal counter > value check to decide if a pass should > be executed or not. Or some other mechanism to provide this feature. > - I am not completely sure but if we are able provide custom callback > feature then we may be able to remove OptBiset and OptPassGate > class. > > Anything missed here? > > Please share your thoughts. > -Vivek > > On Thu, May 3, 2018 at 12:34 AM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote: > >> As a point of clarification, optnone is already being handled by the pass >> i...

As a point of clarification, optnone is already being handled by the pass itself in the legacy implementation. The skip[IR unit] functions are provided by the pass base classes, and the attribute is checked there. This happens any time the legacy wrapper is run, no matter how it is run. Regarding the opt-bisect design, I’m not particularly fond of the managed static either, but I do want to

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

On Tue, May 1, 2018 at 10:52 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Vivek, > > > > Have you read the mailing list threads on this topic? I don’t believe > we’re quite ready to make the switch yet. There was a discussion last > October about what was left to be done. I’m sure it has been discussed > since then too. Here’s a link to the start of

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