search for: insert_imp

...under some strange impression last night that SmallPtrSetImpl wasn't a template. The patch is incorrect because the SmallPtrSetImpl is neither a template nor has an "insert" function... After a detailed look at the header of SmallPtrSet, I found that the SmallPtrSetImpl has an "insert_imp" function which accepts void pointer as argument, and the "insert" function in SmallPtrSet simply cast the incoming pointer to void* by the "PtrTraits::getAsVoidPointer" function and pass the void pointer to insert_imp. So I wonder can we make SmallPtrSetImpl become a temp...

...because the return value is changed from r222334. But the comment of the function is same with before as follows: /// insert - This returns true if the pointer was new to the set, false if it /// was already in the set. std::pair<iterator, bool> insert(PtrType Ptr) { auto p = insert_imp(PtrTraits::getAsVoidPointer(Ptr)); return std::make_pair(iterator(p.first, CurArray + CurArraySize), p.second); } If the comment is changed, please change it. Thanks, JinGu Kang

...taching to process with: process attach -p 92084 Process 92084 stopped Executable module set to "/Users/morbo/llvm/llvm-clean.obj/Release+Asserts/bin/clang". Architecture set to: x86_64-apple-macosx. (lldb) bt * thread #1: tid = 0xbebaf, 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 frame #1: 0x000000010c5147df clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + 47 frame #2: 0x0...

...process attach -p 92084 > Process 92084 stopped > Executable module set to "/Users/morbo/llvm/llvm-clean.obj/Release+Asserts/bin/clang". > Architecture set to: x86_64-apple-macosx. > (lldb) bt > * thread #1: tid = 0xbebaf, 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP > frame #0: 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 > frame #1: 0x000000010c5147df clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + 47 > f...

...p 92084 >> Process 92084 stopped >> Executable module set to "/Users/morbo/llvm/llvm-clean.obj/Release+Asserts/bin/clang". >> Architecture set to: x86_64-apple-macosx. >> (lldb) bt >> * thread #1: tid = 0xbebaf, 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP >> frame #0: 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 >> frame #1: 0x000000010c5147df clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + 47 &gt...

...stopped > >> Executable module set to > "/Users/morbo/llvm/llvm-clean.obj/Release+Asserts/bin/clang". > >> Architecture set to: x86_64-apple-macosx. > >> (lldb) bt > >> * thread #1: tid = 0xbebaf, 0x000000010c5f6dc1 > clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = > 'com.apple.main-thread, stop reason = signal SIGSTOP > >> frame #0: 0x000000010c5f6dc1 > clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 > >> frame #1: 0x000000010c5147df > clang`llvm::DebugInfoFinder::processSubprogram(llv...

...le set to >> >> "/Users/morbo/llvm/llvm-clean.obj/Release+Asserts/bin/clang". >> >> Architecture set to: x86_64-apple-macosx. >> >> (lldb) bt >> >> * thread #1: tid = 0xbebaf, 0x000000010c5f6dc1 >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = >> >> 'com.apple.main-thread, stop reason = signal SIGSTOP >> >> frame #0: 0x000000010c5f6dc1 >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 >> >> frame #1: 0x000000010c5147df >> >> cla...

...gt;> "/Users/morbo/llvm/llvm-clean.obj/Release+Asserts/bin/clang". > >> >> Architecture set to: x86_64-apple-macosx. > >> >> (lldb) bt > >> >> * thread #1: tid = 0xbebaf, 0x000000010c5f6dc1 > >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = > >> >> 'com.apple.main-thread, stop reason = signal SIGSTOP > >> >> frame #0: 0x000000010c5f6dc1 > >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 > >> >> frame #1: 0x000000010c5147df &...

On Sun, Jul 14, 2013 at 10:17 AM, Star Tan <tanmx_star at yeah.net> wrote: > Hi Sebastian, > > Yes, you have pointed an important reason. If we comment this source code > you have listed, then the compile-time overhead for oggenc*8.ll can be > reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). > > I just sent another mail to explain why polly-detect pass leads to >

...sers/morbo/llvm/llvm-clean.obj/Release+Asserts/bin/clang". >> >> >> Architecture set to: x86_64-apple-macosx. >> >> >> (lldb) bt >> >> >> * thread #1: tid = 0xbebaf, 0x000000010c5f6dc1 >> >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = >> >> >> 'com.apple.main-thread, stop reason = signal SIGSTOP >> >> >> frame #0: 0x000000010c5f6dc1 >> >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 >> >> >> frame #1: 0x00...

Hi Sebastian, Yes, you have pointed an important reason. If we comment this source code you have listed, then the compile-time overhead for oggenc*8.ll can be reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). I just sent another mail to explain why polly-detect pass leads to significant compile-time overhead. Besides the reason you have pointed, another reason is resulted from those string

...% caching_compile caching_compiler_test [.] llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) + 1.10% caching_compile caching_compiler_test [.] operator new(unsigned long) + 1.07% caching_compile caching_compiler_test [.] llvm::SmallPtrSetImpl::insert_imp(void const*) + 1.00% caching_compile caching_compiler_test [.] llvm::PMDataManager::removeNotPreservedAnalysis(llvm::Pass*) + 0.99% caching_compile caching_compiler_test [.] operator delete(void*) + 0.69% caching_compile caching_compiler_test [.] llvm::sys::MemoryFence() + 0.64% c...

This series of patches address several issues causing memory usage to grow indefinetely on a long lived process. These are not convenional leaks -- memory would have been freed when the LLVM context or/and JIT engine is destroyed -- but for as long as they aren't the memory is usage effectively ubounded. The issues were found using valgrind with '--show-reachable=yes' option: 1.