search for: bugspynet

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) fn->eraseFromParent(); fn = cast<Function>(module->getOrInsertFunction(name, fnType)); fillFunction(fn); //Fill function with

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); &g...

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 >> that my code doesn't cause the leak >> while(true) >> { >>  Function *fn =...

...nce yourself : runFunction -> getPointerToFunction ->getPointerToGlobalIfAvailable which returns the native address of the jitted function. You can even try to measure time needed by each runFunction to run to double-convince yourself. :) Olivier. On Thu, Mar 18, 2010 at 9:21 AM, Gabi <bugspynet at gmail.com> wrote: > Hello > I have the following scenario, and I am not sure why the performance > is so bad (take 30 minutes to complete with very simple generated > functions): > > 1. Create module > 2. Do something like EE = > EngineBuilder(theModule).setEngineKind...

Hello I have the following scenario, and I am not sure why the performance is so bad (take 30 minutes to complete with very simple generated functions): 1. Create module 2. Do something like EE = EngineBuilder(theModule).setEngineKind(EngineKind::JIT).create(); 3. Create a function in the module: theModule->getOrInsertFunction(..) 4. Execute 1000 times the function using

...e`. (We need to reproduce your problem locally in order to fix it.) Note that if the leaks appear on http://google1.osuosl.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/5/steps/test-llvm/logs/stdio we already know about them and are working on fixes. On Tue, Mar 23, 2010 at 12:42 PM, Gabi <bugspynet at gmail.com> wrote: > Hi Jeffrey, > Listed below the Full valgrind report (using latest revision r99309) > The program creates many thousands of instructions and values as you > can see from the report below > > ...

...is not cached and lives as long as the JIT, so if you use runFunction repeatedly you will be generating many snippets of machine code and leaking memory. The leak could be fixed by freeing the stub before returning its return value. Hope that helps, Reid On Fri, Mar 19, 2010 at 5:27 AM, Gabi <bugspynet at gmail.com> wrote: > Reid, > > Thanks! You were right! > Changing the code to: > > float (*theF)(float) = (float (*)(float)) EE -> getPointerToFunction(f); > float retVal = theF(arg1); > > made the difference. Now it is dozens of times faster! > > I don'...

Reid, Thanks! You were right! Changing the code to: float (*theF)(float) = (float (*)(float)) EE -> getPointerToFunction(f); float retVal = theF(arg1); made the difference. Now it is dozens of times faster! I don't really understand the cause though.. Why doesn't ExecutionEngine cope well with "define float @someFunc(float %x)" and needs this trick ? (but copes well with

Hi, The following arbitrary example makes the code generators to get stuck (llvmc won't return from command line, Jit won't return from function call) Basically it is a CFG with circles, (the function will return by comparing a branch counter to a threshold on runtime - see the "Brancher" blocks below) Any idea what goes wrong? Is it a bug in llvm ? ; ModuleID =

Hi Jeffrey, Listed below the Full valgrind report (using latest revision r99309) The program creates many thousands of instructions and values as you can see from the report below ==20504== Memcheck, a memory error detector ==20504== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==20504== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==20504==

I think I found the cause. It appears that FP operations and functions (I used combinations of CreateFMulL CreateFAdd and CreateFSub ) is MUCH slower than their integer equivalents. I mean really slower (20x slower or even more) Can It be the cause ? Does the FP binary ops are so slow ? -- Regards, Gabi http://bugspy.net

Hi all, This question was probably asked million times before, but I wasted few hours and didn't find the solution.. What is the best way to traverse a large array (say size of million) with GetElementPtr The problem with the following code, is that it forces you to create million constant index values: intVars = new AllocaInst(Type::getInt32Ty(ctx), allocaSize, "intVars",

Is there a way to make the printer to display float values in decimal form instead of the cryptic 0x... ? -- Regards, Gabi http://bugspy.net

> PS: Maybe not for x86 long double though. Right, so how to make x86 double displayed in decimal ? -- Regards, Gabi http://bugspy.net

I need to count the total number of instructions in a given module. The only way I found is using the obvious double iteration as seen below. Is there any more efficient way to achieve this ? I don't like the fact that simple calculation like that has performance of o(F*B) (# of functions * # of blocks per function) unsigned int calcSize(Module* mod) { unsigned int size = 0; for

I get this message once in a while and llvm exits the program. What might be the cause ? llvm version: svn host: Linux x86_64 -- Regards, Gabi http://bugspy.net

Hi Christoph I am compiling for x86-64. This error happens randomly (at least it appears that way) and rarely. About every few thousand runs -- Regards, Gabi http://bugspy.net