similar to: RFC: Use closures to delay construction of optimization remarks

> 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

Hi all, I tried to poke my head into opt-report a while ago and didn't get very far. Now I'm looking at it again. I'm not sure I understand everything that's in place so my question here may be misguided. I'm trying to understand the way strings are handled. When a remark is emitted, it seems that the string is constructed on the fly based on streaming inputs. For example,

This is a first step towards to full iterative compilation framework for Clang/LLVM. The attached patch is work in progress and the idea of sending it to the list earlier rather than later is to open up a discussion on iterative compilation in Clang/LLVM. All comments are welcome, especially those related to integration of the framework into Clang/LLVM. Current compilers have pipeline structure

Hi, I’m looking at RegBankSelect’s partially implemented support for deciding to split a value between multiple registers and I’m wondering if it’s actually intended to solve the problem I’m trying to use it for. RegisterBankInfo.h has this example mapping table: /// E.g., /// Let say we have a 32-bit add and a <2 x 32-bit> vadd. We /// can expand the /// <2 x 32-bit> add into

Hal, Thank you for finding interest in our work! Please find my answers inlined below. > > ________________________________________ > From: Hal Finkel [hfinkel at anl.gov] > Sent: Monday, December 16, 2013 4:26 PM > To: Radovan Obradovic > Cc: llvmdev at cs.uiuc.edu; chandlerc; Andrew Trick > Subject: Re: [LLVMdev] [RFC] Iterrative compilation framework for Clang/LLVM >

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

Radovan, Thanks for posting this! I would really like to have this kind of functionality available. There are a lot of things to think through here; comments inline... ----- Original Message ----- > From: "Radovan Obradovic" <Radovan.Obradovic at imgtec.com> > To: llvmdev at cs.uiuc.edu > Sent: Monday, December 16, 2013 11:31:21 AM > Subject: [LLVMdev] [RFC]

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

Hi Radovan, I am also interested in the iterative compilation in LLVM, and had implemented a simple iterative compilation driver. I guess you do not need to embedded the pointer to ModuleDecisionTreeProxies into the core classes of llvm, i.e. the PassManager class and the Function class. Instead, you could: 1. Implement a special pass manager that runs a set of passes iteratively. Implementing

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

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

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

On 08/12/2010 09:41 PM, Douglas do Couto Teixeira wrote: > Dear guys, > > I am having problems to obtain good information from the LoopInfo. > I am always getting a trip count of 0, even though I am clearly passing > a loop with a constant bound. I am using this pass below: Hi, I would propose to first check if the trip count is calculated correctly. I would do this with opt