search for: zhizhou

...der 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 > opt-bisect should control it wasn't mean to be read as "optimization > level". I think Zhizhou was saying that it should be able to disable > individual optimization steps within a pass. Like if a particular run of > InstCombine made 20 changes, opt-bisect should be able to skip each of > those changes. I think this is the combining opt-bisect with debug > counters idea that'...

...tly have a draft on OptBisect porting implementation, and I am willing to have people review it if you like. Thanks for taking your time on those questions. If anyone is also make similar effort on it, or have any suggestions of implementation, please let me know and I really appreciate :) Best, Zhizhou -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180606/22799f73/attachment.html>

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

...it would become more powerfuly automatically. I've always wanted a bugpoint that could point not just to a pass but to a specific transformation within a pass. -David Fedor Sergeev via llvm-dev <llvm-dev at lists.llvm.org> writes: > On 06/08/2018 08:36 PM, Zhizhou Yang wrote: > > Thanks Craig, that's exactly what I mean, stopping at particular > changes inside a pass. > > PassInstrumentation at its current base design only instruments Pass > execution from a caller (PM) side. > Stopping at a particular change inside a pass de...

...ave already built a bisection tool to help Android toolchain debug on our side. So I will say that the bisecting idea with OptBisect and DebugCounter helps us save time while debugging mis-compilations. Feel free to post if you have other ideas on this and hope that this thread can help. Thanks, Zhizhou -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180918/5b40141f/attachment.html>

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

...ther people have 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! 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

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

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