search for: densemapbase

...owed to call lld::elf::link in 2 different threads at the same time? Follows is an example Valgrind error I ran into when doing the above. I'll try putting a global resource lock on invoking LLD and see if it solves the problem. ==5467== Invalid write of size 8 ==5467== at 0x525509: llvm::DenseMapBase<llvm::DenseMap<llvm::CachedHashStringRef, int, llvm::DenseMapInfo<llvm::CachedHashStringRef>, llvm::detail::DenseMapPair<llvm::CachedHashStringRef, int> >, llvm::CachedHashStringRef, int, llvm::DenseMapInfo<llvm::CachedHashStringRef>, llvm::detail::DenseMapPair<llvm::C...

...>> >> Follows is an example Valgrind error I ran into when doing the above. >> >> I'll try putting a global resource lock on invoking LLD and see if it >> solves the problem. >> >> ==5467== Invalid write of size 8 >> ==5467== at 0x525509: llvm::DenseMapBase<llvm::DenseMap<llvm::CachedHashStringRef, >> int, llvm::DenseMapInfo<llvm::CachedHashStringRef>, >> llvm::detail::DenseMapPair<llvm::CachedHashStringRef, int> >, >> llvm::CachedHashStringRef, int, llvm::DenseMapInfo<llvm::CachedHashStringRef>, >> l...

...GlobalMap[a] = GlobalMap[b]; } When compiled with Clang, ends up like this: define void @_Z4copyPvS_(i8*, i8*) #1 { %3 = alloca i8*, align 8 %4 = alloca i8*, align 8 store i8* %0, i8** %3, align 8 store i8* %1, i8** %4, align 8 %5 = call dereferenceable(8) i8** @_ZN4llvm12DenseMapBaseINS_8DenseMapIPvS2_NS_12DenseMapInfoIS2_EENS_6detail12DenseMapPairIS2_S2_EEEES2_S2_S4_S7_EixERKS2_(%"class.llvm::DenseMapBase"* getelementptr inbounds (%"class.llvm::DenseMap", %"class.llvm::DenseMap"* @GlobalMap, i32 0, i32 0), i8** dereferenceable(8) %4) %6 = load...

...CallbackVH, llvm::SCEV const*, llvm::DenseMapInfo<llvm::Value*>, llvm::detail::DenseMapPair<llvm::ScalarEvolution::SCEVCallbackVH, llvm::SCEV const*> >::getBuckets (this=0x78) at /home/ebdavis/Documents/llvm-project/llvm/include/llvm/ADT/DenseMap.h:739 #1 0x00000000009b1a45 in llvm::DenseMapBase<llvm::DenseMap<llvm::ScalarEvolution::SCEVCallbackVH, llvm::SCEV const*, llvm::DenseMapInfo<llvm::Value*>, llvm::detail::DenseMapPair<llvm::ScalarEvolution::SCEVCallbackVH, llvm::SCEV const*> >, llvm::ScalarEvolution::SCEVCallbackVH, llvm::SCEV const*, llvm::DenseMapInfo<llv...

I actually ran into an elusive bug with this exact same issue some time ago as well, see https://bugs.llvm.org/show_bug.cgi?id=42065 and https://reviews.llvm.org/D62624. The strange thing about that bug was that it only showed up if built with GCC; Clang dereferenced the right hand side reference before evaluating the left hand side, as long as the value type was as small as the reference

...DataFlowValue V); /* confluence operation */ }; } with the following function definition: void DataFlowValue::set(DMTy emap) { ExprMap = *emap; //Line153: } When I compile, I get the following error: /home/zeus/masterLLVM/llvm/include/llvm/ADT/DenseMap.h: In member function ‘void llvm::DenseMapBase<DerivedT, KeyT, ValueT, KeyInfoT>::destroyAll() [with DerivedT = llvm::DenseMap<{anonymous}::Expression, unsigned int>, KeyT = {anonymous}::Expression, ValueT = unsigned int, KeyInfoT = llvm::DenseMapInfo<{anonymous}::Expression>]’: /home/zeus/masterLLVM/llvm/include/llvm/ADT/Dens...

...h seem out of place and accounting for the vast majority of the time.     5.72%; 635,008 Calls; llvm::PMTopLevelManager::findAnalysisPass(void const*) <cycle 4>     4.54%; 3,722,489 Calls; llvm::PMDataManager::findAnalysisPass(void const*, bool)'2     4.11%; 4,604,499 Calls; bool llvm::DenseMapBase<>::LookupBucketFor<>(void const* const&, llvm::detail::DenseMapPair<> const*&) const Also of interest, given the high call count:     1.32%; 6,915,882 Calls; llvm::FoldingSetNodeID::AddInteger(unsigned int) <cycle 4> The call counts seem quite high given the size...

...} > > with the following function definition: > > void DataFlowValue::set(DMTy emap) { > ExprMap = *emap; //Line153: > } > > When I compile, I get the following error: > > /home/zeus/masterLLVM/llvm/include/llvm/ADT/DenseMap.h: In member function > ‘void llvm::DenseMapBase<DerivedT, KeyT, ValueT, KeyInfoT>::destroyAll() > [with DerivedT = llvm::DenseMap<{anonymous}::Expression, unsigned int>, KeyT > = {anonymous}::Expression, ValueT = unsigned int, KeyInfoT = > llvm::DenseMapInfo<{anonymous}::Expression>]’: > /home/zeus/masterLLVM/llvm/i...

...st majority of the time. > > 5.72%; 635,008 Calls; llvm::PMTopLevelManager::findAnalysisPass(void > const*) <cycle 4> > > 4.54%; 3,722,489 Calls; llvm::PMDataManager::findAnalysisPass(void > const*, bool)'2 > > 4.11%; 4,604,499 Calls; bool > llvm::DenseMapBase<>::LookupBucketFor<>(void const* const&, > llvm::detail::DenseMapPair<> const*&) const > > Also of interest, given the high call count: > > 1.32%; 6,915,882 Calls; llvm::FoldingSetNodeID::AddInteger(unsigned > int) <cycle 4> > > The cal...

...oid*) /usr/local/google/home/blaikie/dev/llvm/src/lib/Support/Unix/Signals.inc:481:1 #2 0x1f01653 SignalHandler(int) /usr/local/google/home/blaikie/dev/llvm/src/lib/Support/Unix/Signals.inc:198:60 #3 0x7f6893e22340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x1ae3a9f bool llvm::DenseMapBase<llvm::SmallDenseMap<void*, std::pair<llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Metadata*>, unsigned long>, 4u, llvm::DenseMapInfo<void*>, llvm::detail::DenseMapPair<void*, std::pair<llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Metadata*>, unsigned long...

...ts (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 5000000 samples % image name symbol name 38 57.5758 no-vmlinux /no-vmlinux 2 3.0303 ld-2.19.so _dl_lookup_symbol_x 2 3.0303 libLLVMCore.so llvm::DenseMapBase<llvm::DenseMap<void const*, llvm::PassInfo const*, llvm::DenseMapInfo<void const*> >, void const*, llvm::PassInfo const*, llvm::DenseMapInfo<void const*> >::getHashValue(void const* const&) 2 3.0303 libLLVMCore.so std::vector<llvm::PassInfo const*,...

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 >

...ed) with a unit > mask of 0x00 (No unit mask) count 5000000 > samples % image name symbol name > 38 57.5758 no-vmlinux /no-vmlinux > 2 3.0303 ld-2.19.so _dl_lookup_symbol_x > 2 3.0303 libLLVMCore.so > llvm::DenseMapBase<llvm::DenseMap<void const*, llvm::PassInfo const*, > llvm::DenseMapInfo<void const*> >, void const*, llvm::PassInfo const*, > llvm::DenseMapInfo<void const*> >::getHashValue(void const* const&) > 2 3.0303 libLLVMCore.so std::vector<llvm::Pa...

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

I'm trying to run the example described at: http://llvm.org/docs/DebuggingJITedCode.html I followed the sample command line session (below, with versions numbers for everything), but gdb doesn't stop at the breakpoints as described. Any idea what is wrong? Thanks, Zach zdevito at derp:~/terra/tests$ > ~/clang+llvm-3.4-x86_64-unknown-ubuntu12.04/bin/clang -cc1 -O0 -g >