similar to: Question about opt-report strings

> On Sep 16, 2017, at 4:49 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Actually maybe something like: > > if (auto &E = ORE.emitMissed(DEBUG_TYPE)) { > E.emit(...) << ...; > } Well, the point of this interface was exactly to avoid writing a conditional. If you’re willing to use a conditional you can already write this: if

Sean, hopefully you’re OK with that reasoning. I went ahead and committed this in r313691. > On Sep 16, 2017, at 10:43 PM, Adam Nemet <anemet at apple.com> wrote: > > >> On Sep 16, 2017, at 4:49 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >> >> Actually maybe something like: >> >> if (auto &E

Another alternative could be: ORE.emitMissed(DEBUG_TYPE, ...) << ... Then the first line of emitMissed does a check if it is enabled and if not then returns a dummy stream that does nothing for operator<< (and short-circuits all the stream operations) On Sep 15, 2017 2:21 PM, "Adam Nemet via llvm-dev" <llvm-dev at lists.llvm.org> wrote: For better readability we

Hi Tobias On Wed, Jun 24, 2015 at 12:43 PM, Tobias Grosser <tobias at grosser.es> wrote: > Maybe have a look at Polly's lib/Analysis/ScopDetectionDiagnostic.cpp and > lib/Analysis/ScopDetection.cpp. We use LLVM's diagnostics in a loadable > module without modifying LLVM's DiagnosticKind enum. > Thanks very much for the suggestion. It looks like Polly's

Hi all, Is there a good way to add out-of-LLVM-source subclasses, without modifying the corresponding in-source "Kind" enumeration? As I play around with writing an AA pass, I'd like a good way to issue warnings for cases where my AA pass can't handle a particular IR construct. I was thinking to report those warnings via *llvm::LLVMContext::diagnose( const DiagnosticInfo &

In include/llvm/ADT/Statistic.h, the identifier “DEBUG_TYPE” is never defined. I’ve noticed it’s defined as different things in a few other header files, including llvm/Analysis/BlockFrequencyInfoImpl.h, llvm/Analysis/RegionInfoImpl.h, llvm/Support/UnicodeCharRanges.h, llvm/Transforms/InstCombine/InstCombineWorkList.h, and llvm/Transforms/Utils/SSAUpdaterImpl.h. Should I edit Statistic.h so that

Moving this discussion here from the review thread. RIght now, we have a few passes that prefix DEBUG message with various things, so folks using -debug can tell where the debug message came from. But this is not consistent, and in fact, most passes don't do it. Worse, the prefixes used do not often match the DEBUG_TYPE of the pass. It would be nice to fix this, and just have the DEBUG

----- Original Message ----- > From: "Matthias Braun via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, November 2, 2015 1:16:18 PM > Subject: Re: [llvm-dev] Prefixing DEBUG messages with DEBUG_TYPE (was re: [PATCH] D13259: LLE 6/6: Add

Thank you, I tried to compile it with llvm 3.4 through these commands: petsas at shinigami:~/software/poolalloc$ ./configure --with-llvmsrc=/home/petsas/software/llvm --with-llvmobj=/home/petsas/software/llvm petsas at shinigami:~/software/poolalloc$ make but I'm getting get this error: make[1]: Entering directory `/home/petsas/software/poolalloc/lib' make[2]: Entering directory

On Saturday 19 December 2009 00:16, Chris Lattner wrote: > > Or I think I can just assume (Yikes!) that if the signal handler is > > invoked it will really be a circular_raw_ostream since the handler > > should (!) only be set up in debug mode. > > > > That scares me a bit, though. > > Why don't you just check #ifndef NDEBUG like the code that sets it up?

> On Jul 14, 2017, at 10:22 AM, Davide Italiano <davide at freebsd.org> wrote: > > On Fri, Jul 14, 2017 at 10:10 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote: >> >> >> On Jul 14, 2017, at 8:21 AM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Mon, Jun 19, 2017 at 4:13 PM, Brian

I can generate debug info using opt like this: opt < a.bc > /dev/null -mypass -debug But I don't know how to do it using llc. I check http://llvm.org/docs/CommandGuide/llc.html there are not any information about debug flags. Purpose EX: I want to print all the DEBUG(dbgs()......) in llvm/lib/CodeGen/RegAllocGreedy.cpp . What should I do? -------------- next part -------------- An HTML

On Dec 18, 2009, at 6:36 PM, David Greene wrote: >>> +// Signal handlers - dump debug output on termination. >>> +static void debug_user_sig_handler(void *Cookie) >>> +{ >>> + llvm::circular_raw_ostream *logout = >>> + dynamic_cast<llvm::circular_raw_ostream *>(&llvm::dbgs()); >> >> Please do not use dynamic_cast, we're

On 2009-12-21 18:06, David Greene wrote: > On Saturday 19 December 2009 00:16, Chris Lattner wrote: > > >>> Or I think I can just assume (Yikes!) that if the signal handler is >>> invoked it will really be a circular_raw_ostream since the handler >>> should (!) only be set up in debug mode. >>> >>> That scares me a bit, though. >>>

On Friday 18 December 2009 19:56, Chris Lattner wrote: > > +// -debug-buffer-size - This is a command line op0tion to set the > > size > > +// of the debug stream circular buffer. The value is the number of > > +// characters to save. > > +static cl::opt<unsigned> > > +DebugBufferSize("debug-buffer-size", > > +

Hi, I'm attempting to do some alias analysis & other memory inspection. I've written a pointless AliasAnalysis pass (that says everything must alias) to attempt to verify that my pass is getting picked up & run by opt. I run opt with: opt -load ~/Applications/llvm/lib/MustAA.so -must-aa -aa-eval -debug < trace0.ll I see my pass being initialized, but never being called (I see

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

Hi, Matthias. >From the class hierarchy, ScheduleDAGMILive is also a ScheduleDAGMI. I am wondering if there will be any problem if we use subclass of ScheduleDAGMILive as post-RA scheduler? The best case is ScheduleDAGMILive just waste time on book-keeping register pressure, but I am not sure if we can still do those book-keeping after RA. Talk about post-RA scheduler, I see there is another

On Sep 24, 2007, at 3:15 PM, Dale Johannesen wrote: > > On Sep 24, 2007, at 3:07 PM, Bill Wendling wrote: > >> A debug or release build? >> >> -bw > > Both, actually. Weird. I see a potential problem, though. The code is like this: void dumpToDOUT(SparseBitVector<> *bitmap) { dump(*bitmap, DOUT); } where dump expects an llvm::OStream& for the

All, I'm seeing duplication of DICompileUnits in a pass that worked in 3.8. I assume I'm doing something wrong. Would someone be willing to point me in the right direction? The below minimized pass reproduces my issue in 4.0 with the following error: DICompileUnit not listed in llvm.dbg.cu !1707 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang