similar to: [LLVMdev] RFC: Reduce the memory footprint of DIEs (and DIEValues)

With just those four patches, memory usage went *up* slightly. Add in the 5th patch (which does #2 below), and we get an overall memory drop of 4%. The intermediate result of a memory increase makes sense. While the first four patches reduce the number of (and size of) `DIEValue` allocations, they increase the cost of the `SmallVector` overhead. 0005 (attached) squeezes the abbreviation data

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it

> On 2015 May 20, at 17:51, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > >> On 2015 May 20, at 17:39, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >> With just those four patches, memory usage went *up* slightly. Add in >> the 5th patch (which does #2 below), and we get an overall memory drop >> of 4%. > >

Thanks, I'll look into that. (Though earlier you told me that debug info for types could be extended while walking the IR, so I wouldn't have thought that would have worked.) Peter On Fri, Feb 05, 2016 at 03:52:19PM -0800, David Blaikie wrote: > Will look more closely soon - but I'd really try just writing out type > units to MC as soon as they're done. It should be

Hello All, I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks

On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > Hello All, > > I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final

On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > > On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > >> Hello All, >> >> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"

Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +

I recently updated my version of LLVM from revision 140108 to 142082, and several things broke, most of which were easily fixed. However, I'm now getting a "pure virtual method called" exception (__cxa_pure_virtual) which I wasn't getting before. This is happening in the destructor of a statically-initialized object. (More precisely, it's blowing up in a BumpPtrAllocator,

On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > I recently updated my version of LLVM from revision 140108 to 142082, and > several things broke, most of which were easily fixed. However, I'm now > getting a "pure virtual method called" exception (__cxa_pure_virtual) which > I wasn't getting before. This is happening in the destructor of

Hi all (No idea if I have the correct audience. Please CC more people as needed). I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. The problem is that lld requests that we StringRef::copy an empty string. This passes a length of 0 to a BumpPtrAllocator. The BumpPtrAllocator happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think

Hi, I was having a little trouble installing clang.... while llvm installs properly but clang gives this error on invoking make in Clang make[2]: Leaving directory `/home/na2271/Desktop/llvm-2.3-x/tools/clang/lib/Headers' make[2]: Entering directory `/home/na2271/Desktop/llvm-2.3-x/tools/clang/lib/Basic' llvm[2]: Compiling SourceManager.cpp for Release build SourceManager.cpp: In member

W dniu 2012-10-26 16:55, Daniel Kłobuszewski pisze: > Hello, > > Recently I found binaries produced with LLVM impossible to debug under > Windows. This was probably related to the following bug: > http://llvm.org/bugs/show_bug.cgi?id=13636 > > Asm generated from .ll files revealed that some offsets to debug > information were incorrect: they were absolute instead of

Two functions in DwarfDebug, addBlockByrefAddress() and addComplexAddress(), contain this snippet of code: // Decode the original location, and use that as the start of the byref // variable's location. const TargetRegisterInfo *RI = Asm->TM.getRegisterInfo(); unsigned Reg = RI->getDwarfRegNum(Location.getReg(), false); DIEBlock *Block = new (DIEValueAllocator) DIEBlock();

I'll preface by saying I'm new to LLVM - I noticed there is an efficient BumpPtrAllocator - however, I can't figure out how I can allocate IR objects using that allocator. It looks like all the factory methods use regular new/delete. I'm sure someone BumpPtrAllocator is there for a good reason, and someone here has thought of this use case before. Anyone want to comment? Is

> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in

In various debug dumps (eg., Clang's -ast-dump), various objects (eg., Stmts and Decls in that -ast-dump) are identified by pointers. It's very reliable in the sense that no two objects would ever have the same pointer at the same time, but it's unpleasant that pointers change across runs. Having deterministic identifiers instead of pointers would aid debugging: imagine a

Hi Ted, Doug said you might have a clang-based checker that would detect when people allocate memory with a BumpPtrAllocator and then construct a class into it that needs destruction. In killing valgrind-found memory leaks in LLVM, I've found several instances of this mistake. They often involve SmallVectors, which only show up as leaks in valgrind if they happen to overflow their static

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a BumpPtrAllocator. The