> 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 ExecutionEngine (which automatically deletes TargetMachine and Module) after each compilation. The LLVMContext and IRBuilder objects are deleted after some configurable number of compilations, in order to avoid unbounded growth in the constant pool. We're currently using LLVM 3.3 in production (due to performance regressions in newer versions), so I don't know if some other scheme is appropriate for current levels. - Chuck
On Sun, Jan 18, 2015 at 7:12 AM, Caldarale, Charles R < Chuck.Caldarale at unisys.com> wrote:> > 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.At least in theory all those lazy static objects should be re-initialized when they're first used after a call to llvm_shutdown (bits of the code clearly intend this to be a supported scenario) but it's probably under-tested & I'm not sure if people have ideas about killing it off (so I'm not sure if the right path forward is to avoid relying on that behavior so it can be killed, or to fix the bugs).> We delete the ExecutionEngine (which automatically deletes TargetMachine > and Module) after each compilation. The LLVMContext and IRBuilder objects > are deleted after some configurable number of compilations, in order to > avoid unbounded growth in the constant pool. >Yeah, I don't believe the context's constant pool growth has been addressed even in recent versions.> > We're currently using LLVM 3.3 in production (due to performance > regressions in newer versions), so I don't know if some other scheme is > appropriate for current levels. > > - Chuck > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150118/12fefe5d/attachment.html>
Hi Chuck,> We're currently using LLVM 3.3 in production (due to performanceregressions in newer versions), so I don't know if > some other scheme is appropriate for current levels. Do you have any insight into what regressed? If it's related to the JIT infrastructure I'd be curious to hear about that so I can keep it in mind while working on these new APIs. Slowdowns in IR/CodeGen are also interesting, though I'm less likely to be able to deal with them personally. Cheers, Lang. On Sun, Jan 18, 2015 at 7:12 AM, Caldarale, Charles R < Chuck.Caldarale at unisys.com> wrote:> > 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 ExecutionEngine > (which automatically deletes TargetMachine and Module) after each > compilation. The LLVMContext and IRBuilder objects are deleted after some > configurable number of compilations, in order to avoid unbounded growth in > the constant pool. > > We're currently using LLVM 3.3 in production (due to performance > regressions in newer versions), so I don't know if some other scheme is > appropriate for current levels. > > - Chuck > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/a020cd09/attachment.html>
Just a heads up: The patch is now up for review on llvm-commits. If you have comments related to the patch please post them in that thread. Cheers, Lang. On Mon, Jan 19, 2015 at 8:43 PM, Lang Hames <lhames at gmail.com> wrote:> Hi Chuck, > > > > We're currently using LLVM 3.3 in production (due to performance > regressions in newer versions), so I don't know if > some other scheme is > appropriate for current levels. > > Do you have any insight into what regressed? If it's related to the JIT > infrastructure I'd be curious to hear about that so I can keep it in mind > while working on these new APIs. Slowdowns in IR/CodeGen are also > interesting, though I'm less likely to be able to deal with them personally. > > Cheers, > Lang. > > > On Sun, Jan 18, 2015 at 7:12 AM, Caldarale, Charles R < > Chuck.Caldarale at unisys.com> wrote: > >> > 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 ExecutionEngine >> (which automatically deletes TargetMachine and Module) after each >> compilation. The LLVMContext and IRBuilder objects are deleted after some >> configurable number of compilations, in order to avoid unbounded growth in >> the constant pool. >> >> We're currently using LLVM 3.3 in production (due to performance >> regressions in newer versions), so I don't know if some other scheme is >> appropriate for current levels. >> >> - Chuck >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/917d2ada/attachment.html>
From: Lang Hames [mailto:lhames at gmail.com] Subject: Re: [LLVMdev] New JIT APIs> > We're currently using LLVM 3.3 in production (due to performance regressions in newer > > versions), so I don't know if some other scheme is appropriate for current levels.> Do you have any insight into what regressed?The differences were noted using our standard in-house benchmarks, and we haven't really had the time to do much EMON- and instruction-level research into the differences (the product isn't out the door yet). One of the problems may be in register allocation, since there seemed to be more spills and reloads; there's no evidence that MCJIT itself was an issue. We'll be able to start checking out 3.6 (or 3.7) in detail in June or thereabouts. - Chuck