search for: optpassgates

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

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

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

...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] On Behalf Of Kaylor, Andrew via llvm-dev >         Sent: Thursday,...

...iption 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] On > Behalf Of Kaylor, Andrew via llvm-...

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

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

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

...he 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: ll...

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

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

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

Hello all, After reading OptBisect and DebugCounter related code and playing bit around it I have following simple design: - Add a debug counter for opt-bisect. Initilize it against option -opt-bisect-limit=<limit>. - DebugCounter is a singleton class so can be accessed by both new and legacy passmanager. We may need few more static method like getCounterIdForName(std::string &Name)

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 >

Hi Vivek, can you elaborate why you're looking for a one-size-fits-all solution? What is the noteworthy benefit over adding a new-pm specific implementation? Several changes you mention are purely for the benefit of supporting the legacy PM (which already has a working, tried, and tested solution). E.g. `getCounterIdForName`, the FIXMEs you mention, and the callbacks. All of these are

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

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.

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