search for: debug_typ

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

...the obtained results and some questions and suggestions as well. I was investigating idea to deduplicate debug types information. Idea is described at p276 of DWARF4 specification (http://www.dwarfstd.org/doc/DWARF4.pdf). It suggests to split types information out of .debug_info and emit multiple .debug_types sections with use of COMDATs. Both clang and gcc I tested implements -fdebug-types-section flag for that: -fdebug-types-section, -fno-debug-types-section Place debug types in their own section (ELF Only) gcc's description is here: https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Debugging-Option...

...sion 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 macros output the debug type in front of messages if that's what folks want. Of course, it turns out you can't just make the DEBUG macro do something here, because people use it for more than just outputting messages. My...

...er, in a fairly traditional model, and that is where type sections will provide the most benefit. Your data, then, is essentially for a best-case scenario. Other kinds of projects will not benefit as much. Regarding DWARF 5 and emitting type sections into the .debug_info section rather than the .debug_types section: The work to support DWARF 5 in LLVM has not gotten very far yet. Conforming to the standard in this respect is certainly on my list, however there are other features that Sony considers higher priority. If you or someone else wants to contribute that feature sooner, that would be exce...

...as 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 > LoopLoadElimination pass) > > To ask a basic question first: Why do we need prefixes at all? Are > the messages that likely to be confused? As far as I understand this > case it was only mentioned because of inconsistent prefix/no-prefix >...

Hello DWARF fans, I've just posted a set of four refactoring patches for DebugInfo/DWARF, which move in the direction of handling DWARF v4 or v5 type units and compile units more coherently. In DWARF v4, type units and compile units are strictly segregated into the .debug_types and .debug_info sections, respectively. This division was pretty ingrained into how DebugInfo/DWARF handled the units. In DWARF v5, type units and compile units are all in the .debug_info section, and the .debug_types section is obsolete. So, we need to have a container than can handle both ki...

> 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 (ORE.allowExtraAnalysis(DEBUG_TYPE)) ORE.emit(OptimizationRemark(…) << …; But again the point...

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

...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 = 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 (ORE.allowExtraAnalysis(DEBUG_TYPE)) > ORE.emit(OptimizationRemark(…)...

...> > I was investigating idea to deduplicate debug types information. Idea is > > described at > > p276 of DWARF4 specification (http://www.dwarfstd.org/doc/DWARF4.pdf). > It > > suggests > > to split types information out of .debug_info and emit multiple > > .debug_types sections > > with use of COMDATs. Both clang and gcc I tested implements > > -fdebug-types-section flag for that: > > > > -fdebug-types-section, -fno-debug-types-section > > Place debug types in their own section (ELF Only) > > gcc's description is here: ht...

...-Dave Index: include/llvm/Support/Debug.h =================================================================== --- include/llvm/Support/Debug.h (revision 91748) +++ include/llvm/Support/Debug.h (working copy) @@ -28,6 +28,8 @@ namespace llvm { +class raw_ostream; + /// DEBUG_TYPE macro - Files can specify a DEBUG_TYPE as a string, which causes /// all of their DEBUG statements to be activatable with -debug-only=thatstring. #ifndef DEBUG_TYPE @@ -72,15 +74,20 @@ #define DEBUG_WITH_TYPE(TYPE, X) do { } while (0) #endif +/// dbgs() - This returns a reference to a raw_...

...;m getting get this error: make[1]: Entering directory `/home/petsas/software/poolalloc/lib' make[2]: Entering directory `/home/petsas/software/poolalloc/lib/DSA' llvm[2]: Compiling CallTargets.cpp for Debug+Asserts build (PIC) CallTargets.cpp:35:3: error: use of undeclared identifier 'DEBUG_TYPE' STATISTIC (DirCall, "Number of direct calls"); ^ /home/petsas/software/llvm/include/llvm/ADT/Statistic.h:165:38: note: expanded from macro 'STATISTIC' static llvm::Statistic VARNAME = { DEBUG_TYPE, DESC, 0, 0 } ^ CallTargets.cpp:36:...

...rything 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, ORE->emit([&]() { return OptimizationRemark(DEBUG_TYPE, "LoadElim", LI) << "load of type " << NV("Type", LI->getType()) << " eliminated" << setExtraArgs() << " in favor of " << NV("InfavorOfValue", AvailableValue); });...

...astructure to deal > with lookup, etc so may end up being as much churn as a. b is more > useful if we think other users of metadata may want/need similar > functionality in the future. I can't say I've followed all the details but would this be useful in moving toward support of .debug_types at all? There's a superficial resemblance in conjuring up hashes of types referenced from elsewhere, and I can't help wondering if the resemblance is any deeper than that. (I'm not insisting that it has to be, at worst it shouldn't get in the way if we can anticipate what would...

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

...sume debug sections are unique in object, so in that case we looks want to error out). Have last thoughts/question about this though :) Currently clang -gdwarf-5 -fdebug-types-section​ works. And so linker can deduplicate types. Though that probably violates specification saying there is no more .debug_type sections. But behavior is convinent for users of -fdebug-types-section. I do not know how transition from v4 to v5 will happen/happens (or how transition between dwarf standarts usually happens). I suppose one day clang just will start to produce v5 debug data by default. And at the same time mult...

Currently, LLVM's DWARF parser keeps Compile Units and Type Units on separate lists, basically organizing them by ELF section. This works okay for DWARF v4, because Type Units are in .debug_types (possibly in individual COMDATs) and everything else is in the .debug_info section (without COMDATs). The two lists conveniently can be templated/typed with DWARFTypeUnit and DWARFCompileUnit. In DWARF v5, Type Units (possibly with COMDATs) are in .debug_info and there is no .debug_types sectio...

...ot always possible, for example we have to look inside .eh_frame to deuplicate FDEs, but that is probably what we would want to avoid in general. >It doesn't seem especially important to implement the DWARF5 types -> debug_info thing for this situation, the type units >as they are (in debug_types) offer the same size benefits here. But sure, if anyone wanted to implement it at some point, that'd be fine. But there is no .debug_types in DWARF5, so it is depricated approach as far I understand. >I think Paul covered some of the reasons type units might not be a reasonable default....

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