search for: debugcount

Hi all, Debugging a mis-compilation is always time consuming. I recently did some attempt on bisecting bad pass for LLVM and would like to share some ideas about how do we make it work. And meanwhile, I would also encourage the community to make each pass more bisectable with help of DebugCounter. We have already got a very useful helper in LLVM for pass level bisection, which is OptBisect <https://llvm.org/docs/OptBisect.html>. Though it only works for legacy pass manager, Fedor proposed an on-going effort <https://reviews.llvm.org/D50923> to make similar things work for new...

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

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 generation involves some passes which are mandatory (e.g. isel). -Eli -- Employee of Qualcomm Innovation...

...Eli > <efriedma at codeaurora.org> wrote: > > 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 > generation involves some passes whic...

...DEBUG: Inside SSHD Filter ---------------------- SSHD End ------------------------- Looking at file /usr/share/logwatch/scripts/services/sshd there is block of code starting at line 165: ... if ( $Debug >= 5 ) { print STDERR "\n\nDEBUG: Inside SSHD Filter \n\n"; $DebugCounter = 1; } while (defined(my $ThisLine = <STDIN>)) { if ( $Debug >= 5 ) { print STDERR "DEBUG($DebugCounter): $ThisLine"; $DebugCounter++; } ... >From above, this line never prints anything: print STDERR "DEBUG($DebugCounter): $ThisLine"; while th...

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

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

...unterIdForName`, the FIXMEs you mention, and the callbacks. All of these are heavyweight changes, but I don't see an upside of going this direction. Cheers, Philip 2018-05-06 10:59 GMT+02:00 vivek pandya <vivekvpandya at gmail.com>: > 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. >...

...mantics to C level and those lowerings are absolutely required for the code to be runnable. regards,   Fedor. On 09/26/2018 08:47 PM, Philip Pfaffe 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. > > Cheers, > Philip > > On Wed, Sep 26, 2018 at 6:54 PM Fedor Sergeev via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>...

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

...tion/finalization purposes)   3. custom callbacks are registered with PassInstrumentation::register* interfaces      A sequence of registered callbacks is called at each instrumentation point as appropriate.   4. introduce llvm::ExecutionCounter to track execution of passes      (akin to DebugCounter, yet enabled in Release mode as well?)      Note: it is somewhat nontrivial to uniquely track pass executions with counters in new pass      manager as its pipeline schedule can be dynamic. Ideas are welcome on how to efficiently      implement unique execution tracking that does not break...

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

...zation/finalization purposes) 3. custom callbacks are registered with PassInstrumentation::register* interfaces A sequence of registered callbacks is called at each instrumentation point as appropriate. 4. introduce llvm::ExecutionCounter to track execution of passes (akin to DebugCounter, yet enabled in Release mode as well?) Note: it is somewhat nontrivial to uniquely track pass executions with counters in new pass manager as its pipeline schedule can be dynamic. Ideas are welcome on how to efficiently implement unique execution tracking that does not break in...

...e registered with > PassInstrumentation::register* interfaces > >       A sequence of registered callbacks is called at each > instrumentation point as appropriate. > >    4. introduce llvm::ExecutionCounter to track execution of passes > >       (akin to DebugCounter, yet enabled in Release mode as well?) > >       Note: it is somewhat nontrivial to uniquely track pass > executions > with counters in new pass >       manager as its pipeline schedule can be dynamic. Ideas are > welcome > on how to efficiently >...

...ef > ARMAttributeParser.h > ARMBuildAttriubtes.h > ARMEHABI.h > ARMTargetParser.def > ARMWinEH.h > Binary*Stream*.h > BlockFrequency.h > BranchProbability.h > CachePruning.h > CBindingWrapping.h > CodeGen.h > CodeGenCWrappers.h > COFF.h > Compression.h > DebugCounter.h > DotGraphTraits.h > Dwarf.def > Dwarf.h > DynamicLibrary.h > ELF.h > GCOV.h > GenericDomTree.h > GenericDomTreeConstruction.h > GraphWriter.h > LEB128.h > LockFileManager.h > LowLevelTypeImpl.h > MachO.def > MachO.h > MipsABIFlags.h > OnDiskHashT...

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

...>>>> >>>> A sequence of registered callbacks is called at each >>>> instrumentation point as appropriate. >>>> >>>> 4. introduce llvm::ExecutionCounter to track execution of passes >>>> >>>> (akin to DebugCounter, yet enabled in Release mode as well?) >>>> >>>> Note: it is somewhat nontrivial to uniquely track pass executions >>>> with counters in new pass >>>> manager as its pipeline schedule can be dynamic. Ideas are >>>> welcome &g...

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:

...ef > ARMAttributeParser.h > ARMBuildAttriubtes.h > ARMEHABI.h > ARMTargetParser.def > ARMWinEH.h > Binary*Stream*.h > BlockFrequency.h > BranchProbability.h > CachePruning.h > CBindingWrapping.h > CodeGen.h > CodeGenCWrappers.h > COFF.h > Compression.h > DebugCounter.h > DotGraphTraits.h > Dwarf.def > Dwarf.h > DynamicLibrary.h > ELF.h > GCOV.h > GenericDomTree.h > GenericDomTreeConstruction.h > GraphWriter.h > LEB128.h > LEB128.h seems quite generic. > LockFileManager.h > LowLevelTypeImpl.h > MachO.def > MachO...

...d at > each > instrumentation point as appropriate. > > 4. introduce llvm::ExecutionCounter to track > execution of passes > > (akin to DebugCounter, yet enabled in Release mode > as well?) > > Note: it is somewhat nontrivial to uniquely track > pass executions > with counters in new pass > manager as its...