search for: debug_types

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

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

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

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

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

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

> 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

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

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

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

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?

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

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,

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

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

...d ( https://gcc.gnu.org/wiki/DebugFissionDWP ). Sure DWP do great job here it seems, but even for DWP use case flow it does not look make sence to force compiler to do excessive job to produce types sections, ​because DWP producing tools probably should have no benefit from larger .dwo files with .debug_types at all I think. I can only imagine now that somebody could use -gsplit-dwarf​ and -fdebug-types-section together so that can parse .debug_types.dwo instead of parsing .debug_info.dwo to look for types in a bit more convinent way, but that looks too synthetic case. >In short, I probably wouldn&...

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

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

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