search for: managedstat

I'm curious about the design rationale for how ManagedStatic instances are cleaned up, and I'm hoping someone can shed some light on it. Currently, ManagedStatic objects are cleaned up when llvm_shutdown() traverses the global list of initialized objects and calls destroy() on each. This leads to two questions: 1. An assertion enforces that the obje...

Right, I'm suggesting we keep llvm_shutdown() for users who want this control, but also destroy still-live ManagedStatic instances if llvm_shutdown() is not called. This helps in the case where there is not a clear time when llvm_shutdown() can be called, especially given that LLVM cannot be resurrected in the same process due to current limitations in the pass registry, and perhaps elsewhere. On Wed, Feb 13, 20...

...nt discussion[1], I started trying to remove the functions llvm_start_multithreaded() and llvm_stop_multithreaded() from the codebase. It turns out this is a little bit tricky. Consider the following scenario: During program initialization, a global static object's constructor dereferences a ManagedStatic. During dereferencing of the ManagedStatic, it needs to know whether or not to acquire the global lock in order to allocate the ManagedStatic There are 3 possible types for the global_lock, and none of them solve the problem. 1) If global_lock is simply another global static, it may not have b...

The mutex could be made an actual global static instead of a ManagedStatic. This guarantees it would be constructed before main, and live until the end of main. So even in PassRegistry's destructor, which would get call during llvm_shutdown(), it would always have the same mutex. Ideally I'd like to just delete the mutex, as it doesn't seem like anyone is...

...g a problem, because of a subtle bug involving static initialization order and shutdown. In particular, the RegisterPass<> static template will get invoked during static initialization and call PassRegistry::getPassRegistry()->registerPass(*this); Note that PassRegistry, however, is a ManagedStatic. So the call to getPassRegistry() creates the backing object of the ManagedStatic here. Then registerPass gets called, which attempts to lock the mutex. This will initialize the backing object of the SmartRWMutex. During shutdown, it happens in reverse order. First the SmartRWMutex is destro...

...n order and shutdown. > > > > In particular, the RegisterPass<> static template will get invoked during > > static initialization and call > > > > PassRegistry::getPassRegistry()->registerPass(*this); > > > > Note that PassRegistry, however, is a ManagedStatic. So the call to > > getPassRegistry() creates the backing object of the ManagedStatic here. > > Then registerPass gets called, which attempts to lock the mutex. This > will > > initialize the backing object of the SmartRWMutex. > > > > During shutdown, it happen...

...ith our proprietary linker, which links against libLTO dynamically. The issue is that when we pass -time-passes via the lto_codegen_debug_options function in the LTO C API, no time information is produced during compilation. The reason for this is that time information is stored in state owned by a ManagedStatic instance, and is only printed when the state is destroyed. This in turn only happens when ManagedStatics are cleaned up, via the llvm_shutdown function. As we do not link against LLVM (except libLTO dynamically), we have no access to llvm_shutdown, which in turn means we are not able to clean up...

...9;: gtest.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED5Ev]+0x15): undefined reference to `pthread_getspecific' % Linking CXX executable SupportTests CMakeFiles/SupportTests.dir/ManagedStatic.cpp.o: In function `(anonymous namespace)::Initialize_MultipleThreads_Test::TestBody()': ManagedStatic.cpp:(.text+0x9a): undefined reference to `pthread_create' ManagedStatic.cpp:(.text+0xb7): undefined reference to `pthread_create' ManagedStatic.cpp:(.text+0xc8): undefined reference...

...ind under our internal application. The stack traces I get are: ==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12 ==19966== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==19966== by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>() (ManagedStatic.h:25) ==19966== by 0x5E05AB6: llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const (ManagedStatic.cpp:47) ==19966== by 0x5D9B73E: llvm::ManagedStatic<llvm::PassRegistry>::operator*() (ManagedStatic.h:67) ==19966== by 0x5D997E1: llvm::PassRegistry::getP...

Here is the warning I am getting: PseudoSourceValue.cpp R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(23) : warning C4156: deletion of an array expression without using the array form of 'delete'; array form substituted R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(72) : see reference to function template instantiation 'void llvm::object_deleter<C>(void *)...

Hi all, I observe that r220932 (Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex.) is causing tablegen to segfault in PPC platforms during static initialization. The crash happens while calling std::call_once introduced by this patch in the wrapper used in getManagedStaticMutex. I understand this call is bugg...

...> linker, which links against libLTO dynamically. The issue is that when we > pass -time-passes via the lto_codegen_debug_options function in the LTO C > API, no time information is produced during compilation. The reason for > this is that time information is stored in state owned by a ManagedStatic > instance, and is only printed when the state is destroyed. This in turn > only happens when ManagedStatics are cleaned up, via the llvm_shutdown > function. As we do not link against LLVM (except libLTO dynamically), we > have no access to llvm_shutdown, which in turn means we are n...

Manish Verma <manish.avtaar at gmail.com> writes: > I am attaching a patch which fixes the above mentioned failures. Could you > please review the patch? [snip] > index 79eb098..6419653 100644 > --- a/unittests/Support/ManagedStatic.cpp > +++ b/unittests/Support/ManagedStatic.cpp > @@ -9,7 +9,7 @@ > #include "llvm/Support/ManagedStatic.h" > #include "llvm/Config/config.h" > #include "llvm/Support/Threading.h" > -#ifdef HAVE_PTHREAD_H > +#ifdef LLVM_ENABLE_THREADS !=0 &amp...

...ou using? > BE or LE? > > Copying Adhemerval in case he has heard of any related issues. > > Thanks, > Bill > > On Mon, 2014-11-03 at 20:19 -0500, Samuel F Antao wrote: > > Hi all, > > > > I observe that r220932 (Removing the static initializer in > > ManagedStatic.cpp by using llvm_call_once to initialize the > > ManagedStatic mutex.) is causing tablegen to segfault in PPC platforms > > during static initialization. The crash happens while calling > > std::call_once introduced by this patch in the wrapper used in > > getManagedStat...

...eload_memcheck-amd64-linux.so) ==26332== by 0x165CC6C: llvm::sys::MutexImpl::MutexImpl(bool) (Mutex.cpp:49) ==26332== by 0xD41D5A: llvm::sys::SmartMutex<true>::SmartMutex(bool) (Mutex.h:94) ==26332== by 0xD3E81F: void* llvm::object_creator<llvm::sys::SmartMutex<true> >() (ManagedStatic.h:26) ==26332== by 0x165AA95: llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const (ManagedStatic.cpp:50) ==26332== by 0xD3C372: llvm::ManagedStatic<llvm::sys::SmartMutex<true> >::operator*() (ManagedStatic.h:68) ==26332== by 0x1605FE2: llvm::Pas...

...re too? It seems like you'd want to avoid anything >>> too >>> fancy since LLVM has to run on so many different architectures with >>> their variety of memory semantics, etc. >> >> I totally agree. However, at least one case of thread-unsafety >> (ManagedStatic), has proven very-difficult-to-impossible to implement >> correctly without using lower-level operations. >> > > Yes, double-checked locking is a pain. There's a C++ safe > implementation > in > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.htm...

...issues. > > > > > > Thanks, > > > Bill > > > > > > On Mon, 2014-11-03 at 20:19 -0500, Samuel F Antao wrote: > > > > Hi all, > > > > > > > > I observe that r220932 (Removing the static initializer in > > > > ManagedStatic.cpp by using llvm_call_once to initialize the > > > > ManagedStatic mutex.) is causing tablegen to segfault in PPC > > platforms > > > > during static initialization. The crash happens while calling > > > > std::call_once introduced by this patch in the...

...gher level locking constructs. Is > that the plan here too? It seems like you'd want to avoid anything too > fancy since LLVM has to run on so many different architectures with > their variety of memory semantics, etc. I totally agree. However, at least one case of thread-unsafety (ManagedStatic), has proven very-difficult-to-impossible to implement correctly without using lower-level operations. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available URL: <http://lis...

...DenseMapAPFloatKeyInfo::KeyTy,llvm::ConstantFP *,A0x5b1fa632::DenseMapAPFloatKeyInfo>::DenseMap<`anonymous namespace'::DenseMapAPFloatKeyInfo::KeyTy,llvm::ConstantFP *,A0x5b1fa632::DenseMapAPFloatKeyInfo>(unsigned int NumInitBuckets=64) Line 68 C++ Fibonacci.exe!llvm::ManagedStatic<llvm::DenseMap<`anonymous namespace'::DenseMapAPFloatKeyInfo::KeyTy,llvm::ConstantFP *,A0x5b1fa632::DenseMapAPFloatKeyInfo> >::LazyInit() Line 72 + 0x24 bytes C++ Fibonacci.exe!llvm::ManagedStatic<llvm::DenseMap<`anonymous namespace'::DenseMapAPFloatKey...

...ics on their platform. > Our problems are actually deeper than that, because we need to > interact well with static constructors. This means that we can't > use a mutex with a non-constant initializer, or else we can't depend > on it being properly initialized before the ManagedStatic is > accessed. While this would be possible with pthread mutexes, I know > of no good way to do it for Windows CRITICAL_SECTION's. Actually, global static constructors are evil and should be eliminated. No static constructors should do anything non-trivial, and it is essentia...