search for: deletebodi

On Wednesday 09 July 2008 13:49, David Greene wrote: > > then it seems you're doing > > > > for each function > > generate_ir > > convert_to_llvm_ir > > optimize_llvm_ir > > Yep. Ok, I've mostly got a mechanism to do what I want: 1. As each function comes in for op/codegen, clone it and save off the clone and its associated ValueMap (I

On Wednesday 09 July 2008 13:24, Devang Patel wrote: > Is it possible to explain intended use of original unoptimized version ? bugpoint. I want to run it on the IR produced by our frontend. This will help us generate new LLVM tests we can send upstream. We've fixed bugs that aren't caught by the upstream tests and it would be nice to capture the problem and make the test

I think you need to call "llvm::Function::deleteBody() first" On Tue, Mar 23, 2010 at 15:49, Reid Kleckner <rnk at mit.edu> wrote: > On Tue, Mar 23, 2010 at 7:04 AM, Gabi <bugspynet at gmail.com> wrote: >> Hi >> I get huge memory leaks using LLVM IRBuilder (trunk version) >> >> Basically I recreate a function over and over again, and pretty sure

On Jul 11, 2008, at 9:59 AM, David Greene wrote: > On Wednesday 09 July 2008 13:49, David Greene wrote: > >>> then it seems you're doing >>> >>> for each function >>> generate_ir >>> convert_to_llvm_ir >>> optimize_llvm_ir >> >> Yep. > > Ok, I've mostly got a mechanism to do what I want: > > 1. As

Owen Anderson wrote: > That wasn't going to be possible with the methods-on-LLVMContext > either. The Type uniquing tables will be moving onto the context for > similar reasons to the Constant ones, though we will make an effort to > preserve the existing APIs. OK. > > I'm not sure I understand your goal with having one context per > function. The goal is to

On 9/28/07, Chris Lattner <sabre at nondot.org> wrote: > > > MachineCodeEmitter [3] is obtainable from the JIT class, and it > > contains "BufferBegin", "BufferEnd", and "CurBufferPtr" as protected > > members; if they were available, determining the generated code size > > might be possible via some pointer arithmetic. Is there

On Sep 28, 2007, at 10:27 AM, Sandro Magi wrote: > In my quest to account for memory, I've now come to the in-memory IR, > and the generated code. I want to book the generated code memory > against the agent that is generating the code. > > I see that LLVM's Function class [1] has a size function; what does > this represent and can I use it to account for the space used

Nicholas, > What if I want to have global llvm::Type's, that can be used by many > LLVMContext's. For example, I'd like to have one LLVMContext per > function, and be able to create constants that belong to the context > but using a global, shared amongst LLVMContext's, llvm::Type. > > I know that's not doable right now, but aren't we losing this >

On Mon, Jan 14, 2013 at 4:56 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello all, > > I've already bothered people on IRC with this question and it was > recommended to ask it here. > > First of all, some context. In Rubinius (http://rubini.us/, > http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create > LLVM IR using the C++ API and

In my quest to account for memory, I've now come to the in-memory IR, and the generated code. I want to book the generated code memory against the agent that is generating the code. I see that LLVM's Function class [1] has a size function; what does this represent and can I use it to account for the space used by the in-memory IR? As for generated code, the JIT [2] class simply returns a

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

Hello all, I've already bothered people on IRC with this question and it was recommended to ask it here. First of all, some context. In Rubinius (http://rubini.us/, http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create LLVM IR using the C++ API and turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the

Hi, I am trying to replace a c-style function with another function with same signature. Consider the following code: std::stringstream main_c; main_c <<"#include <stdio.h>\n" <<"extern \"C\" { \n" <<"int print1()\n" <<"{\n" <<" printf(\"Inside

On Thu, Feb 11, 2010 at 6:53 PM, James Williams <junk at giantblob.com> wrote: > Hi, > > I'm seeing rather high memory usage from LLVM and I'd like to track down > what I'm doing to cause it. My application is a simple web application > server that compiles web pages with embedded script to bitcode and compiles > them with the JIT on demand. I've taken

Hi, I'm seeing rather high memory usage from LLVM and I'd like to track down what I'm doing to cause it. My application is a simple web application server that compiles web pages with embedded script to bitcode and compiles them with the JIT on demand. I've taken tools/lli.cpp as a starting point and extended it to load additional modules. However, if I load successive pages and

Hi Gael I am sorry that I couldn't explain what I was trying to say, anyway I've got the answer :) . In the *parseFunction* method returns *llvmfunction* pointer of compiled method and then it will be stored in to cache. Could you please more elaborate on how those machine instructions ( native functions) executing by llvm. I was trying trace and I couldn't able to find

Hi Chris, thanks for your answers! [large executables] > It depends on what you're building. A release build of LLVM (make > ENABLE_OPTIMIZED=1, with the results in llvm/Release) is > significantly smaller than a debug build. Even with that, however, > the binaries are larger than they should be (5M?). Noone has spent > the time to track down why this is to my

On Mon, Jun 8, 2015 at 11:33 AM, Reid Kleckner <rnk at google.com> wrote: > The clang patch lgtm, and I had some comments on the LLVM patch. Duncan, do > you want to say more there? > > --- include/llvm/Transforms/IPO/PassManagerBuilder.h (revision 237590) > +++ include/llvm/Transforms/IPO/PassManagerBuilder.h (working copy) > @@ -121,6 +121,7 @@ class PassManagerBuilder {

But in my module this function already exist… I first want to delete it but without also deleting the calls to it… From: Boldizsar.Palotas at esa.int <Boldizsar.Palotas at esa.int> Sent: Donnerstag, 13. Dezember 2018 10:53 To: Gaier, Bjoern <Bjoern.Gaier at horiba.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Setting a function in a

On Tue, Mar 23, 2010 at 7:04 AM, Gabi <bugspynet at gmail.com> wrote: > Hi > I get huge memory leaks using LLVM IRBuilder (trunk version) > > Basically I recreate a function over and over again, and pretty sure > that my code doesn't cause the leak > while(true) > { >  Function *fn = module->getFunction(name); >    if (fn) >