search for: zhizhouy

...specific use cases. If so, please explain the use > case to me. > > -Andy > > -----Original Message----- > From: Fedor Sergeev [mailto:fedor.sergeev at azul.com] > Sent: Wednesday, September 26, 2018 9:54 AM > To: llvm-dev <llvm-dev at lists.llvm.org>; Zhizhou Yang <zhizhouy at google.com>; > David Greene <dag at cray.com>; David Blaikie <dblaikie at gmail.com>; Kaylor, > Andrew <andrew.kaylor at intel.com>; Chandler Carruth <chandlerc at gmail.com> > Subject: OptBisect implementation for new pass manager > > Greetings! > &g...

...> -Andy > > *From:*Philip Pfaffe [mailto:philip.pfaffe at gmail.com] > *Sent:* Thursday, September 27, 2018 2:46 AM > *To:* Kaylor, Andrew <andrew.kaylor at intel.com> > *Cc:* Fedor Sergeev <fedor.sergeev at azul.com>; llvm-dev > <llvm-dev at lists.llvm.org>; zhizhouy at google.com; dag at cray.com; David > Blaikie <dblaikie at gmail.com>; Chandler Carruth <chandlerc at gmail.com> > *Subject:* Re: [llvm-dev] OptBisect implementation for new pass manager > > Hi Andrew, > > We absolutely need to be able to generate executable pro...

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 my questions about porting the OptBisecting to new PM. This thread looks like a great improvement on what we currently have. Though we are also trying to make opt-bisect more granular. In particular, we...

...ly 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 >> > wrote: >> >> Hi Fedor, >>> >>> Thanks for replying my questions about porting the OptBisecting to new >>> PM. >>> >>> This thread looks like a great improvement on what we currently have. >>> Though we are...

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

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

...Message----- From: David Greene [mailto:dag at cray.com] Sent: Monday, October 01, 2018 7:01 AM To: Fedor Sergeev <fedor.sergeev at azul.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. O...

...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> wrote: > > > > Hi Fedor, > > > Thanks for replying my questions about porting the > OptBisecting to new PM. >...

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

On 10/01/2018 11:13 PM, David Greene wrote: > Philip Pfaffe <philip.pfaffe at gmail.com> writes: >> Sorry, but I strongly oppose to the road you're suggesting here. As I >> said before the Pass*Manager* is entirely the wrong place to handle >> OptNone, the absolutely the wrong design. It makes sense for function >> *only*, and immediately breaks down everywhere