[llvm-dev] Deleting function IR after codegen

[Justin Bogner via llvm-dev]

Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 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.

Did you happen to measure whether it's even worth keeping for
--disable-free? I suppose the cost of deleting it might be enough to
worry about for very small compilations, in which case we'd probably
want to keep the current behaviour.

> I could attach a patch, but first i’d really like to know if anyone is
> fundamentally opposed to this.

I'm definitely interested in seeing the patch. ISTM that anywhere the MC
layer needs to access IR would be a bit of a layering violation already,
so we'd want to clean that up anyway.

> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev