[llvm-dev] Deleting function IR after codegen

[Chandler Carruth via llvm-dev]

FWIW, +1 from me as well.

But I don't think you need to make this a module pass or anything else. I
think you should leave the husks of the functions around and just nuke the
IR out from under them. That way the module surface remains essentially
identical. You can also probably nuke all the instructions from BBs with
their addresses taken for jump tables, etc.

-Chandler

On Tue, Mar 8, 2016 at 1:16 PM Quentin Colombet <qcolombet at apple.com> wrote:

> On Mar 8, 2016, at 11:50 AM, Eric Christopher <echristo at gmail.com> wrote:
>
>
>
>
>> I could attach a patch, but first i’d really like to know if anyone is
>> fundamentally opposed to this.
>>
>>
> Not necessarily. I think that any information that isn't being serialized
> in MI right now for a function could be as well. Definitely something for
> GlobalISel to keep in mind.
>
>
> +1.
> That’s basically where I would like to go with
> MachineModule/MachineModulePass.
> http://lists.llvm.org/pipermail/llvm-dev/2016-January/094426.html
>
> Cheers,
> -Quentin
>
>
>
>> 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.
>>
>
> This is definitely worth it, please go ahead and do this.
>
>
>> - 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.
>>
>
> I think this makes sense, but I worry about late added GlobalValues during
> code gen? How would we cope with that? Example: Let's say we start lowering
> a target specific construct as an MI pass etc and it constructs a global
> value, when do we run the analysis to make sure that all such things
> happen? Late as possible I'd assume. Maybe this isn't an issue, but thought
> I'd bring it up. At any rate, could you provide a bit more detail here?
>
> - 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.
>>
>>
> Oh well. Conveniently there aren't a lot of these.
>
> -eric
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/628ee474/attachment.html>