[llvm-dev] Deleting function IR after codegen

[Pete Cooper via llvm-dev]

> On Mar 7, 2016, at 5:01 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> 
>> On Mar 7, 2016, at 4:44 PM, Pete Cooper <peter_cooper at apple.com> wrote:
>> 
>> Hi all
>> 
>> 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 think such a pass is worth it. 
> I see a conceptual issue with it though, it would have to be FunctionPass, and such pass are not allowed to delete globals and Functions (see http://llvm.org/docs/WritingAnLLVMPass.html#the-functionpass-class ).
Ah, yeah this is tricky.  So my pass isn’t deleting the function value, but it is deleting all the BBs/Instrs inside.  When you read the IR it actually prints it as a declaration because the AsmWriter thinks that no body implies a declaration.

One issue this this is that FPPassManager::runOnFunction starts by checking for declarations and skipping them.  So that means that if a function pass was to run after my pass, then it would get a function with no body which is not what it expects.

One option I considered was to replace the function body with a single BB and an unreachable/return, but I didn’t want to create useless IR.
> That said the CodeGen could be made a CallGraphSCCPass (which is something we thought about investigating to help register allocation at call site when you have already CodeGen the callee and can infer what is preserved). I'm not sure your feature alone justify such a change though.
I would certainly like to see CodeGen work this way.  If my work requires it then I have no problem with it, but i’d love to land my changes without this if its possible, just in case its troublesome to make this change.
> 
> Out of curiosity, how do you expose it to the client by the way:
> 
> Target->addPassesToEmitFile(PM, ....)
> if (deleteFunctionAfterCodeGen)
> 	PM.addPass(createFunctionDeletionPass())
> or 
> 
> Target->addPassesToEmitFile(PM, ...., deleteFunctionAfterCodeGen);
The above.  The specific lines I changed on the function prototype are this, which means that I’m opting everyone in to my change, but then as I said we’d probably change clang to propagate its DisableFree flag in here:

virtual bool addPassesToEmitFile(
       PassManagerBase &, raw_pwrite_stream &, CodeGenFileType,
-      bool /*DisableVerify*/ = true, AnalysisID /*StartBefore*/ = nullptr,
+      bool /*DisableVerify*/ = true, bool /*FreeFunctionIR*/ = true,
+      AnalysisID /*StartBefore*/ = nullptr,
       AnalysisID /*StartAfter*/ = nullptr, AnalysisID /*StopAfter*/ = nullptr,
       MachineFunctionInitializer * /*MFInitializer*/ = nullptr)

Cheers,
Pete
> 
> -- 
> Mehdi
> 
> 
> 
>> 
>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160307/7ec6668a/attachment.html>