similar to: LLVM Fatal Error Handling

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

However I need the standard assignment operator so I can assign the value of a temporary to that of another temporary, or to create a new temporary from an existing one. - Paul ________________________________________ From: Tim Northover <t.p.northover at gmail.com> Sent: 16 March 2016 13:11 To: Paul Hancock Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] IRBuilder Assignment (

Hi, We have been investigating an issue when running LTO with 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

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

I partially worked out that to do an assign I will need to manually assign a temporary first and then load data into it, which also means I'll need to set up a temporaries list in my code assembler as allocations must be done before anything else? or is it fine to allocate a variable mid-way through a function and the compiler will manage it? With that as well, if I had a function that loads

Hi, I wanted to get some opinions on this subject before I submit a PR about it. I don't know if there are any pitfalls with the 'fix' I suggested and though it best to run it past people here before submitting. If there's a better place to post this please let me know (freebsd-ports?). The send-pr output I was about to send explains everything so I'll just paste it here:

Chris, I'm using a llvm_shutdown_obj object and it calls llvm_shutdown when I delete it. Do I need to call llvm_shutdown() again afterwards? It looks to me like the static object is being created after my program exits main(). From: Chris Lattner [mailto:clattner at apple.com] Sent: Friday, January 13, 2012 10:11 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev]

> From: Armin Steinhoff [mailto:armin at steinhoff.de] > Subject: Re: [LLVMdev] New JIT APIs > is >  delete EE;   // execution engine >  llvm_shutdown(); > sufficient ? AFAICT, llvm_shutdown() must not be called unless you reach a point where LLVM will not be used again by the process (e.g., termination), as it destroys statically allocated objects. We delete the

2017-05-02 8:42 GMT-07:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>: > +Teresa, Mehdi > > On May 2, 2017, at 08:31, James Henderson <jh7370.2008 at my.bristol.ac.uk> > wrote: > > Hi, > > We have been investigating an issue when running LTO with our proprietary > linker, which links against libLTO dynamically. The issue is that when we > pass

Hi, I am working on a binary translator and use LLVM for this. In the process, I generate millions of constants (immediate values in the source binary code). The problem is that these constants seem to be not cleaned when I delete the LLVM code (using Function::deleteBody() ) and as a result the memory usage keeps growing. I browsed the forum and found that constants "live forever" by

Hey Daniel, thanks for the response. > I believe all you need to do is call llvm::llvm_shutdown(). > I am not sure that this is what I need. When and how should I call llvm_shutdown()? After the FunctionPassManager is done, the calling ModulePass still performs quite a few actions on the transformed code and also calls the FunctionPassManager on different functions. However, I need

Hello everybody, is it somehow possible to get information about what passes were run in what order or timing analysis of passes *without* using opt? I am implementing a ModulePass that at some point creates a FunctionPassManager which runs several passes, but I cannot figure a way to output the same information as when running a command line tool as described in "Writing an LLVM

Where did getBacktrace go? I cant find any changes about it except for it simply disappearing after I updated from 3.8 to 4.0... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/6ca7bce9/attachment.html>

In my code assembly system I have the various LH-RH operators, ADD, ADDF, SUB, etc, using CreateAdd, CreateFAdd, etc, however I cant seem to locate the correct function/s for the assignment operator. What's the correct function/s in the IRBuilder for assigning a value? - Paul -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, What do you recommend for keeping track of user activities? For preserving bash histories I followed these recommendations: http://www.defcon1.org/secure-command.html They include using 'chflags sappnd .bash_history', enabling process accounting, and the like. My goal is to "watch the watchers," i.e. watch for abuse of power by SOC people with the ability to view

Hi Ralf, I believe all you need to do is call llvm::llvm_shutdown(). - Daniel On Sun, Jul 26, 2009 at 11:51 AM, Ralf Karrenberg<Ralf.Karrenberg at gmx.de> wrote: > Hello everybody, > > is it somehow possible to get information about what passes were run in > what order  or timing analysis of passes *without* using opt? > I am implementing a ModulePass that at some point

On Jan 13, 2012, at 10:08 AM, Villmow, Micah wrote: > > Are these known issues? If so, how do I free this memory? > Hi Micah, Please try calling llvm_shutdown() -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120113/a51dc89c/attachment.html>

Is there a simple method for compiling a custom assertion header/call into all the LLVM libraries? I want my application to be able to handle any thrown assertions (ie; as an exception) and recover or crash gracefully. I already have a custom header in place in the application's source, however this doesn't have an effect on [most of] the already compiled lib's. -------------- next

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 using it in a

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>()