search for: smallptrsetimpl

hi, On Sat, Mar 17, 2012 at 2:11 AM, Andrew Trick <atrick at apple.com> wrote: > Yep. I normally do that. I was 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 argume...

Linking CXX executable ../../../../bin/lldb Scanning dependencies of target lldb-platform [100%] Building CXX object tools/lldb/tools/lldb-platform/CMakeFiles/lldb-platform.dir/lldb-platform.cpp.o *../../../../lib/liblldb.so.3.5: undefined reference to `llvm::SmallPtrSetImpl::SmallPtrSetImpl(void const**, unsigned int, llvm::SmallPtrSetImpl&&)'** **clang: error: linker command failed with exit code 1 (use -v to see invocation)** **make[2]: *** [bin/lldb-3.5] Error 1* make[1]: *** [tools/lldb/tools/driver/CMakeFiles/lldb.dir/all] Error 2 make[1]: *** Waiti...

...gt; wrote: > Linking CXX executable ../../../../bin/lldb > Scanning dependencies of target lldb-platform > [100%] Building CXX object > tools/lldb/tools/lldb-platform/CMakeFiles/lldb-platform.dir/lldb-platform.cpp.o > ../../../../lib/liblldb.so.3.5: undefined reference to > `llvm::SmallPtrSetImpl::SmallPtrSetImpl(void const**, unsigned int, > llvm::SmallPtrSetImpl&&)' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [bin/lldb-3.5] Error 1 > make[1]: *** [tools/lldb/tools/driver/CMakeFiles/lldb.dir/all] Error 2 >...

Hi all, I have a compilation failure with 'insert' member function of SmallPtrSetImpl class 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) { au...

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.

...ile as follows (many thanks to Andy Kaylor for creating this reproducer) $ opt -slp-vectorizer -hotcoldsplit -slp-vectorizer -S -o - extract.ll opt: .../llvm/lib/Analysis/CodeMetrics.cpp:107: static void llvm::CodeMetrics::collectEphemeralValues(const llvm::Function*, llvm::AssumptionCache*, llvm::SmallPtrSetImpl<const llvm::Value*>&): Assertion `I->getParent()->getParent() == F && "Found assumption for the wrong function!"' failed. ... The comments in the AssumptionCache seem to indicate that we should never get into this situation because AssumptionCache is supposed...

...ile as follows (many thanks to Andy Kaylor for creating this reproducer) $ opt -slp-vectorizer -hotcoldsplit -slp-vectorizer -S -o - extract.ll opt: .../llvm/lib/Analysis/CodeMetrics.cpp:107: static void llvm::CodeMetrics::collectEphemeralValues(const llvm::Function*, llvm::AssumptionCache*, llvm::SmallPtrSetImpl<const llvm::Value*>&): Assertion `I->getParent()->getParent() == F && "Found assumption for the wrong function!"' failed. ... The comments in the AssumptionCache seem to indicate that we should never get into this situation because AssumptionCache is supposed...

...:964:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’ Lex(); ^~~ ``` ``` /home/dsl11/dev/llvm-upstream/src/lib/Transforms/Scalar/LoopStrengthReduce.cpp: In member function ‘void {anonymous}::Cost::RateRegister(const llvm::SCEV*, llvm::SmallPtrSetImpl<const llvm::SCEV*>&, const llvm::Loop*, llvm::ScalarEvolution&, llvm::DominatorTree&)’: /home/dsl11/dev/llvm-upstream/src/lib/Transforms/Scalar/LoopStrengthReduce.cpp:943:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (!isa<SCEVUnknown>(Reg...

...lldb -p 92084 Attaching 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 f...

...tEngineKind( llvm::EngineKind::JIT ) Where module is a `llvm::Module*`. This is code I'm migrating from 3.3 to 3.8. Since the deletion error is happening during constructor I'm at a bit of a loss as to what I'm doing wrong. The stack trace from gdb is: #0 0x00007ffff1195a02 in llvm::SmallPtrSetImplBase::isSmall (this=0x0) at /opt/llvm/include/llvm/ADT/SmallPtrSet.h:128 #1 0x00007ffff11e37d3 in llvm::SmallPtrSetImplBase::erase_imp (this=0x0, Ptr=0x68c200) at /opt/llvm/lib/Support/SmallPtrSet.cpp:78 #2 0x00007ffff14c9174 in llvm::SmallPtrSetImpl<llvm::Module*>::erase (this=0x0, Ptr=0x68...

...rocess 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) +...

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

...alloc twice for every string you insert.) * FoldingSet uses chaining, which is likely less memory- and time-efficient than open addressing (which pretty much all of our other set classes use). * SmallPtrSet has an interface that lets you operate on an instance without knowing its inline size (SmallPtrSetImpl), but SmallSetVector and SmallDenseSet don't have this. But more to my point, each of these sets has a different API. Some support limited C++11-isms, others don't. Most don't support the full range of stl set operations, but they all pick and choose a different subset of operation...

...gt; 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::processSu...

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

...o > >> >> "/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: 0x000000...

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 >

...>> "/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 >> >> >> fr...

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

...de(), I->getType(), Ops, TD, TLI, + HonorFPExceptions); } static Constant * ConstantFoldConstantExpressionImpl(const ConstantExpr *CE, const DataLayout *TD, const TargetLibraryInfo *TLI, - SmallPtrSetImpl<ConstantExpr *> &FoldedOps) { + SmallPtrSetImpl<ConstantExpr *> &FoldedOps, + bool HonorFPExceptions) { SmallVector<Constant *, 8> Ops; for (User::const_op_iterator i = CE->op_begin(), e = CE->...