similar to: [LLVMdev] How to avoid memory leaks

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==

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

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

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

Hi Gabi, I have no idea why your performances is not as expected with such low level of informations. But, I know that the binary code is cached by the JIT. You can find the code in JIT.cpp to convince yourself : runFunction -> getPointerToFunction ->getPointerToGlobalIfAvailable which returns the native address of the jitted function. You can even try to measure time needed by each

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

On Wed, May 23, 2018 at 3:07 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> >> wrote: >> >>> Hello, >>> >>> I think that the approach of using a

On Thu, May 31, 2018 at 5:13 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 31, 2018 at 5:06 PM Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Wed, May 23, 2018 at 3:07 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Wed, May 23, 2018 at

On Thu, May 31, 2018 at 5:06 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, May 23, 2018 at 3:07 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Wed, May 23, 2018 at 3:25 AM, Peter

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 =

On 23 May 2018 at 23:07, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: >> >> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> >> wrote: >>> >>> Hello, >>> >>> I think that the approach of using a

Hi, after upgrading samba from 4.1.17 to 4.1.19 on OpenSuSE 13.2, any shares offered by this machine can nolonger be accessed, when these shares contain an entry "force group" which specifies a local unix group and when there exists a unix user with the same name. Here's an excerpt from smb.conf: [FactWork] comment = FactWork-Downloadportal path =

Hi Marc, Am 19.03.2015 um 22:53 schrieb Marc Muehlfeld: > Am 19.03.2015 um 14:35 schrieb Nissl Reinhard: >> When I try to access share \\platon\root<file:///\\platon\root> as fee\administrator I get the following: >> >> platon:~ # smbclient -c dir -W fee -U administrator%secret //platon/root >> Domain=[FEE] OS=[Unix] Server=[Samba

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",

On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> > wrote: > >> Hello, >> >> I think that the approach of using a section to record address >> significance is a good one. I'm guessing it will have its own section >> type and format? If

On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> wrote: > Hello, > > I think that the approach of using a section to record address > significance is a good one. I'm guessing it will have its own section > type and format? If it does would it make sense to try and submit this > to the GABI https://groups.google.com/forum/#!forum/generic-abi as

I got replies from Nick Clifton and Michael Matz: https://sourceware.org/pipermail/binutils/2020-November/114116.html (and its reply). I have mentioned (a) the difficulty of the detecting-DWARF64-by-first-relocation approach and (b) the section type approach in my reply there https://sourceware.org/pipermail/binutils/2020-November/114125.html (a) My prototype has made me feel uneasy with this

Linux GABI [1] introduced new .note.gnu.property section which contains a program property note which describes special handling requirements for linker and run-time loader. LLD does not support .note.gnu.property yet. GABI specifies 2 types of entries: GNU_PROPERTY_STACK_SIZE and GNU_PROPERTY_NO_COPY_ON_PROTECTED: * GNU_PROPERTY_STACK_SIZE: Its pr_data field contains an integer in the format

On Fri, Nov 13, 2020 at 11:17 AM David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Nov 13, 2020 at 11:05 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > I got replies from Nick Clifton and Michael Matz: > > https://sourceware.org/pipermail/binutils/2020-November/114116.html > > (and its reply). > > I have mentioned (a) the difficulty

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