similar to: [LLVMdev] Memory allocation (or deallocation) model?

On Mon, 3 Dec 2007, Benjamin Smedberg wrote: > I've been reading the headers and > http://llvm.org/releases/2.1/docs/ProgrammersManual.html and I'm still > confused about a pretty fundamental point... who is expected to clean up > various objects when we're finished with them, and when? Ok, different objects have different life times. The important ones are: (most)

On Mon, 2007-12-03 at 18:56 -0800, Chris Lattner wrote: > Other IR objects (like instructions) have very simple ownership. An > instruction is owned by its basic block, a bb is owned by the function, a > function is owned by thet module. If an instruction is initially allocated with its Instruction *insertAtEnd parameter defaulted to null, and then later appended to a BasicBlock,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What is the expected footprint of a tool using the LLVM JIT? I have created a simple project that uses the LLVM C++ API to JIT calls to XPCOM method signature... it works well, but the component DLL is very large (Linux x86-74, 5.8MB optimized and stripped). Is this normal? Am I linking to "too much" or not using the correct link flags?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm a LLVM newbie who's started experimenting with the JIT, and I have a couple questions relating to LLVM and the runtime JIT: I'm going to post them as separate messages to avoid getting threads tangled up. I want to call a C++ function from a function that was JITted at runtime. I'm starting with HowToUseJIT.cpp as a base for

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anton Korobeynikov wrote: > Benjamin, > >> It seems that LLVM bytecode doesn't have a builtin type for "pointer-sized >> integer". > You should use TargetData to provide a size of pointer. Sorry, perhaps I was not clear. When JITting code it's not hard to figure out the size of a pointer and use the equivalent

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Lattner wrote: > Finally, there is still a lot that can be done to reduce code size. For > example, building a JIT links in the .s file printers in, and they have > non-trivial size (big string tables etc). It would be great to refactor > the code to avoid things like this. I wouldn't be surprised if we could > shrink the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joachim Durchholz wrote: | Subject says it all. | | Looking in /usr/include/gnu, I find stubs-64.h and stubs.h, but no | stubs-32.h. | This is probably related to my machine running a 64-bit install of | Ubuntu. I'm not sure whether this should be rectified in Ubuntu or LLVM. You don't have i386 and x86-64 devel packages installed. Ask your

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There doesn't appear to be a calling convention matching "thiscall"... on gcc targets, the standard calling convention is fine (just pass "this" as the first parameter), but with MSVC this won't work because it passes "this" in %ECX. Is there a workaround for this? Or how hard would it be to add a separate

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems that LLVM bytecode doesn't have a builtin type for "pointer-sized integer". Is there a way to emulate a pointer-size integer type in bytecode without knowing the target processor word size? How hard would it be to add such a type? - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation benjamin at smedbergs.us

Hi Olivier, On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > Hi Garrison, > > I finally come back from holidays and take time to watch your patch. > > I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? JIT::forceEmitFunctionStub(...) was created to

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

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

----- Mensaje original ---- De: Benjamin Smedberg <benjamin at smedbergs.us> Para: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Enviado: viernes, 22 de febrero, 2008 22:36:40 Asunto: Re: [LLVMdev] Calling functions -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Álvaro Castro wrote: | Hello! | | | I'm trying LLVM for generating code and I found

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]

Hi I''m using shorewall 2.1.10 on redhat 9 .. The machine have 2 network card eth1 inside network and eth0 internet(router) I define a static route on the linux system ( route add..) to another router But when I try to ping to the host/router I get "fw kernel : shorewall: forward: reject: in eth1 out=eth1...." Eth1= 192.168.220.254 Route add -net 192.114.122.111 netmask

> 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