search for: managedstatics

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 objects are deleted in reverse order of

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

...zation. 3) If global_lock is a ManagedStatic<Mutex>, then it will get into an infinite recursion here when trying to allocate this ManagedStatic. I actually started to feel this way since the first time I started looking at LLVM, but even moreso increasingly I feel that the solution is that ManagedStatics should not be allowed to be accessed until after main begins. llvm_shutdown() gives deterministic order of destroying managed statics, but we don't have deterministic order of *creation* of those ManagedStatics. I have a patch up[2] (still awaiting review) that shows a possible solution to t...

...>> > However, the current implementation of ManagedStatic is already buggy > >> > for > >> > other reasons, which I've tried to fix, and am now running into this > as > >> > a > >> > result of my fix (true once-only initialization of ManagedStatics). > >> > > >> > I'm curious about the history here. Can we remove the locking from > >> > PassRegistry? And what would it take to get RegisterPass<> to not > rely > >> > on > >> > static initialization. Is there any reason...

...he current code because ManagedStatic "accidentally" allocates another SmartRWMutex. However, the current implementation of ManagedStatic is already buggy for other reasons, which I've tried to fix, and am now running into this as a result of my fix (true once-only initialization of ManagedStatics). I'm curious about the history here. Can we remove the locking from PassRegistry? And what would it take to get RegisterPass<> to not rely on static initialization. Is there any reason why we can't just initialize these at runtime early in main? -------------- next part ---------...

...edStatic "accidentally" allocates another SmartRWMutex. > > However, the current implementation of ManagedStatic is already buggy for > > other reasons, which I've tried to fix, and am now running into this as a > > result of my fix (true once-only initialization of ManagedStatics). > > > > I'm curious about the history here. Can we remove the locking from > > PassRegistry? And what would it take to get RegisterPass<> to not rely > on > > static initialization. Is there any reason why we can't just initialize > > these at run...

...-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 ManagedStatic instances and thus no timing information is produced. We have considered a few options and h...

Hi, I found that building LLVM in single-threaded mode with CMake is failing because some object files still have references to pthread routines. There are two instances of the build failure happening. $ cmake .../llvm/ -DLLVM_ENABLE_THREADS=0 $ make -j8 check-all % Linking CXX executable IRTests ../../lib/libgtest.a(gtest.cc.o): In function

I am trying to figure out how to free up some memory that seems to be lost when running valgrind 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>()

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

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 buggy for some platforms

...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 ManagedStatic instances and thus no timing information is produced. > > We have consid...

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

Hi Bill, You can find the same issue in the buildbot: http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/16444/steps/compile.llvm.stage2/logs/stdio It is failing for me both in BE (gcc 4.8.2) and LE(4.9.1). I am compiling with clang 3.5, but those are the gcc toolchains I am using. What do you think is the best way to fix this? Thanks! Samuel Bill Schmidt <wschmidt at

Hi, I'm Ryo Onodera. This is my first post to this mailing list. Fist, thanks for creating a great library! We're using LLVM to support JIT in Rubinius (an alternative implementation of Ruby, a dynamic programming language). I'm submitting a small patch for a minor issue. It solves still-reachable leak warnings from Valgrind. Example warnings are shown at the end of this mail. As

On May 17, 2009, at 5:23 AM, Luke Dalessandro wrote: > Owen Anderson wrote: >> >> On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: >> >>> Also, atomic ops are usually pretty low level things used for >>> nonblocking algorithms or to build higher level locking >>> constructs. Is >>> that the plan here too? It seems like you'd want

Ok, I'll put a patch together to fix this later today. I'll probably do what Reid was suggesting and use what is already in there for Windows. Thanks, Samuel Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote on 11/04/2014 12:11:08 PM: > From: Bill Schmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: azanella at

On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: > Owen Anderson wrote: >> Some of you may have noticed that I addedd include/llvm/System/ >> Atomics.h >> to the repository briefly, which will be used for adding support for >> threading in LLVM. > > Just out of curiosity, is there a design document somewhere for the > plan > for threading? Not as

Hola LLVMers, I'm getting a crash when using ConstantFP::get. I can repro it by adding one line to the Fibonacci example program: int main(int argc, char **argv) { int n = argc > 1 ? atol(argv[1]) : 24; // Create some module to put our function into it. Module *M = new Module("test"); // We are about to create the "fib" function: Function

On May 16, 2009, at 10:01 PM, Owen Anderson wrote: > OK, I've enhanced Atomic.h by pulling in a bunch of implementations > from libatomic_ops, and others that I could figure out on my own. > > Again, my plea: PLEASE TRY THIS OUT ON YOUR PLATFORM, AND SEND ME > PATCHES IF IT DOESN'T WORK! Similarly, if you think the > implementation could be improved for your