[llvm-dev] Deleting function IR after codegen

[Larry Gritz via llvm-dev]

YES. My use of LLVM involves an app that JITs program after program and will quickly swamp memory if everything is retained. It is crucial to aggressively throw everything away but the functions we still need to execute.

I've been faking it with old JIT (llvm 3.4/3.5) by using a custom subclass of JITMemoryManager that squirrels away the jitted binary code so that when I free the Modules, ExecutionEngine, and MemoryManager, the real memory that got allocated for the binary code is hidden and does not get deallocated.

Currently I'm struggling with bringing my code base up to MCJIT without losing this ability, because the memory consumption is killing me.

Sometimes I think that clang as the canonical user of LLVM does not reflect the diversity of JIT-oriented LLVM use cases. An "offline" compiler like clang gets to exit after compiling a module, but other apps using LLVM may JIT module after module after module indefinitely.

For that kind of use case, it would be great to have as a first-class feature the ability to free the IR of a compiled module, and even better, to throw away the Module and EE entirely but keep the ability to call into the JITed binary function. Many apps would benefit from a stable API for doing this. 

	-- lg


> On Mar 7, 2016, at 4:55 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> After codegen for a given function, the IR should no longer be needed.  In the AsmPrinter we convert from MI->MCInstr, and then we never go back and look at the IR during the MC layer.
> 
> I’ve prototyped a simple pass which can be (optionally) scheduled to do just this.  It is added at the end of addPassesToEmitFile.  It is optional so that clang can continue to leak the IR with --disable-free, but i would propose that all other tools, and especially LTO, would enable it.  The savings are 20% of peak memory in LTO of clang itself.
> 
> I could attach a patch, but first i’d really like to know if anyone is fundamentally opposed to this.
> 
> I should note, a couple of issues have come up in the prototype.
> - llvm::getDISubprogram was walking the function body to find the subprogram.  This is trivial to fix as functions now have !dbg on them.
> - The AsmPrinter is calling canBeOmittedFromSymbolTable on GlobalValue’s which then walks all their uses.  I think this should be done earlier in codegen as an analysis whose results are available to the AsmPrinter.
> - BB’s whose addresses are taken, i.e. jump tables, can’t be deleted.  Those functions will just keep their IR around so no changes there.
> 
> With the above issues fixed, I can run make check and pass all the tests.
> 
> Comments very welcome.
> 
> Cheers,
> Pete

--
Larry Gritz
lg at larrygritz.com