search for: debugcounters

...lt;https://reviews.llvm.org/rL337748>, I added a method to print DebugCounter info: the `-print-debug-counter` flag. With this, writing a transformation level bisection script will be more straightforward. The issue we face is that the transformation level bisection can only work in passes with DebugCounters, and very few passes have these today. DebugCounter is also very useful even a pass author debugs manually without special bisection tooling. So I would encourage the community to add DebugCounter to your own passes to make life easier for debugging. Adding DebugCounters isn’t often too difficult....

...which may happen to be a pass list), but I'd > like to see us somehow retain that capability to isolate the > problematic set of transformations. I wonder if this might be better as a separate tool. The functionality is defintely useful. In fact I'd like to see it enhanced by using DebugCounters when available. This will require some smarts for DebugCounters to either report themselves to the tool or for passes to report their DebugCounter-ness. > bugpoint currently has the ability to debug miscompiles by splitting > the code into a "known good" set of functions (which is...

On 9/26/2018 10:47 AM, Philip Pfaffe via llvm-dev wrote: > Hi Fedor, > > can you make an example where a pass actually needs to opt-out? > Because IMO, bisect should quite literally to DebugCounter-style skip > every step in every ::run method's loop. Passes should not even be > concerned with this. This isn't so much an issue for the optimization pipeline, but code

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 see a plan of how Codegen is going to migrate before the new PM becomes default. Codegen pass pipelines have been wonky ever since I started working with LLVM and it would be nice to get that cleaned up. -David Philip Pfaffe

I having a problem where Logwatch is not showing any events from the /var/log/secure log file. When I run logwatch --print --range today --service sshd --detail 10 --debug 10 the end result shows this: ... LogFiles that will be processed: [0] = secure [1] = messages Made Temp Dir: /var/cache/logwatch/logwatch.sOga48bL with tempdir export LOGWATCH_DATE_RANGE='today' export

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)

But they're deeply connected. I debug codegen problems all the time. That opt-bisect doesn't work with codegen is really unfortunate. If opt-bisect should work with codegen then we need to think about how codegen will work with the new PM. I agree 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

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

Philip, It kinda depends on user expectations. What do you really expect as a result of your compilation when you set -opt-bisect-limit=X? Do you just get a resulting IR and scan for the bad pattern? Then you dont care about pass sequences and do brute-force bisect. Do you expect to get a runnable code at the end and check for buggy run-time behavior? Then you need to keep the passes that 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

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

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

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

On Mon, May 29, 2017 at 9:25 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to

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

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 >

Hey all, I wanted to share a proposal <https://docs.google.com/document/d/171ecPTeXw68fbCghdGw_NPBouWvmvUX8vePlbhhHEdA/edit?usp=sharing> to revamp the current go-to IR debugging tool: Bugpoint. i'd love to hear any feedback or general thoughts. Here's the markdown version of the doc: --- # Bugpoint Redesign Author: Diego Treviño (diegotf at google.com) Date: 2016-06-05 Status:

2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to spend 10 minutes waiting

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.