search for: bumpptr

...ver be freed, and make sure the FileArchive (and other classes implementing find()) managed the memory of the returned file objects. - One other leak is Mach-O specific. TrieNode (in MachONormalizedFileBinaryWriter) uses a SmallVector to store its children. But TrieNodes are allocated using a llvm bumpPtr allocator, and so are never ‘deleted'. While the memory used by the TrieNode is properly released when the allocator is destroyed, the SmallVector destructor is never called and so the contained TrieEdges leak. - The third major leak source is the SimpleReferences stored in SimpleDefinedAtom (...

...the last thing that you want to think about is TableGen's guts, but I'm pursuing a course in bringing TableGen up to snuff with the rest of LLVM. Basically, I would like to introduce a "TGContext" class (by analogy with LLVMContext) to harbor a proper unique'd type system and BumpPtr allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This change should have no effect on the TableGen backends, simply being a refactoring of the internals. One huge bonus in particular from centralizing all of the memory allocation is that I plan to hack in a custom...

...r: ==================== libpoolalloc.so: undefined symbol: _ZTIN4llvm16EquivClassGraphsE -load request ignored. *** 4 DYNAMIC POOLS INITIALIZED *** *** 4 DYNAMIC POOLS ALLOCATED FROM *** MaxHeapSize = 0.062500KB HeapSizeAtExit = 0.062500KB NOTE: only valid if using Heuristic=AllPools and no bumpptr/realloc! ==================== I have tried to link the program with the Analysis and with Datastructure libs: llvm-gcc -o test test.opt.bc -lpoolalloc -lpoolalloc_rt -lLLVMDataStructure -lLLVMAnalysis But I am still receiving the error. Another question, I do not want to use the bump ptr optim...

...ant to think about is > TableGen's guts, but I'm pursuing a course in bringing TableGen up to > snuff with the rest of LLVM. > > Basically, I would like to introduce a "TGContext" class (by analogy > with LLVMContext) to harbor a proper unique'd type system and BumpPtr > allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This > change should have no effect on the TableGen backends, simply being a > refactoring of the internals. > > One huge bonus in particular from centralizing all of the memory > allocation is th...

...ant to think about is > TableGen's guts, but I'm pursuing a course in bringing TableGen up to > snuff with the rest of LLVM. > > Basically, I would like to introduce a "TGContext" class (by analogy > with LLVMContext) to harbor a proper unique'd type system and BumpPtr > allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This > change should have no effect on the TableGen backends, simply being a > refactoring of the internals. Makes sense to me. > One huge bonus in particular from centralizing all of the memory > a...

...he Pool Allocation, but I am receiving this error: > > ==================== > > *** 4 DYNAMIC POOLS INITIALIZED *** > > *** 4 DYNAMIC POOLS ALLOCATED FROM *** > > MaxHeapSize = 0.062500KB HeapSizeAtExit = 0.062500KB NOTE: only valid if using > Heuristic=AllPools and no bumpptr/realloc! > ==================== This output is what happens when you link with the debug version of the runtime library. If you rebuild the FL2Allocator with 'make ENABLE_OPTIMIZED=1' and link with the result, you shouldn't get this. > I have tried to link the program with th...

...rror: > > > > ==================== > > > > *** 4 DYNAMIC POOLS INITIALIZED *** > > > > *** 4 DYNAMIC POOLS ALLOCATED FROM *** > > > > MaxHeapSize = 0.062500KB HeapSizeAtExit = 0.062500KB NOTE: only valid if using > > Heuristic=AllPools and no bumpptr/realloc! > > ==================== > > This output is what happens when you link with the debug version of the > runtime library. If you rebuild the FL2Allocator with 'make > ENABLE_OPTIMIZED=1' and link with the result, you shouldn't get this. > > > I hav...

...is >> TableGen's guts, but I'm pursuing a course in bringing TableGen up to >> snuff with the rest of LLVM. >> >> Basically, I would like to introduce a "TGContext" class (by analogy >> with LLVMContext) to harbor a proper unique'd type system and BumpPtr >> allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This >> change should have no effect on the TableGen backends, simply being a >> refactoring of the internals. > > Makes sense to me. > >> One huge bonus in particular from centrali...

...want to think about is > TableGen's guts, but I'm pursuing a course in bringing TableGen up to > snuff with the rest of LLVM. > > Basically, I would like to introduce a "TGContext" class (by analogy > with LLVMContext) to harbor a proper unique'd type system and BumpPtr > allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This > change should have no effect on the TableGen backends, simply being a > refactoring of the internals. > > One huge bonus in particular from centralizing all of the memory > allocation is tha...

...> ==================== >>> >>> *** 4 DYNAMIC POOLS INITIALIZED *** >>> >>> *** 4 DYNAMIC POOLS ALLOCATED FROM *** >>> >>> MaxHeapSize = 0.062500KB HeapSizeAtExit = 0.062500KB NOTE: only valid if using >>> Heuristic=AllPools and no bumpptr/realloc! >>> ==================== >> >> This output is what happens when you link with the debug version of the >> runtime library. If you rebuild the FL2Allocator with 'make >> ENABLE_OPTIMIZED=1' and link with the result, you shouldn't get this. >&...

...Gen's guts, but I'm pursuing a course in bringing TableGen up to >>> snuff with the rest of LLVM. >>> >>> Basically, I would like to introduce a "TGContext" class (by analogy >>> with LLVMContext) to harbor a proper unique'd type system and BumpPtr >>> allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This >>> change should have no effect on the TableGen backends, simply being a >>> refactoring of the internals. >> >> Makes sense to me. >> >>> One huge bon...

...>> > >>> *** 4 DYNAMIC POOLS INITIALIZED *** > >>> > >>> *** 4 DYNAMIC POOLS ALLOCATED FROM *** > >>> > >>> MaxHeapSize = 0.062500KB HeapSizeAtExit = 0.062500KB NOTE: only valid if using > >>> Heuristic=AllPools and no bumpptr/realloc! > >>> ==================== > >> > >> This output is what happens when you link with the debug version of the > >> runtime library. If you rebuild the FL2Allocator with 'make > >> ENABLE_OPTIMIZED=1' and link with the result, you shou...

Hello, i want to implement a common lisp subset using llvm for fun. This requires the use of a garbage collector. I read the docs, but many things are still unclear to me. 1. how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are

...is >> TableGen's guts, but I'm pursuing a course in bringing TableGen up to >> snuff with the rest of LLVM. >> >> Basically, I would like to introduce a "TGContext" class (by analogy >> with LLVMContext) to harbor a proper unique'd type system and BumpPtr >> allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This >> change should have no effect on the TableGen backends, simply being a >> refactoring of the internals. >> >> One huge bonus in particular from centralizing all of the memory &g...

...but I'm pursuing a course in bringing TableGen up to >>>> snuff with the rest of LLVM. >>>> >>>> Basically, I would like to introduce a "TGContext" class (by analogy >>>> with LLVMContext) to harbor a proper unique'd type system and BumpPtr >>>> allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This >>>> change should have no effect on the TableGen backends, simply being a >>>> refactoring of the internals. >>> >>> Makes sense to me. >>> &gt...

...rs are hard to read and memorize; it's hard to notice the difference between 0x7f80a28325e0 and 0x7f80a28325a0, especially when they're a few screens apart. >> >> Hence the idea: why don't we print the offset into the allocator's memory slab instead of a pointer? We use BumpPtrAllocator all over the place, which boils down to a set of slabs on which all objects are placed in the order in which they are allocated. It is easy for the allocator to identify if a pointer belongs to that allocator, and if so, deteremine which slab it belongs to and at what offset the object is...