llvm dev - May 2016 - Deleting function IR after codegen

> 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/20160308/2634733f/attachment.html>

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>

----- Original Message -----
> From: "Chandler Carruth" <chandlerc at gmail.com>
> To: "Quentin Colombet" <qcolombet at apple.com>, "Eric
Christopher"
> <echristo at gmail.com>
> Cc: "Pete Cooper" <peter_cooper at apple.com>, "Duncan
P. N. Exon Smith"
> <dexonsmith at apple.com>, "Hal Finkel" <hfinkel at
anl.gov>, "Philip
> Reames" <listmail at philipreames.com>, "Mehdi Amini"
> <mehdi.amini at apple.com>, "Rafael Espíndola"
> <rafael.espindola at gmail.com>, "llvm-dev" <llvm-dev at
lists.llvm.org>
> Sent: Thursday, May 12, 2016 6:11:34 PM
> Subject: Re: [llvm-dev] Deleting function IR after codegen
> 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.
I agree. We need to be careful about invalidating inter-procedural IR-level
analysis results that we make use of using CodeGen (like AA). Consider, for
example, the following situation:

1. We CodeGen a function foo(), and then remove its IR. During this process, we
never used an AA query that reached CFL-AA
2. We CodeGen a function bar(), and bar() calls foo(). 
3. During (2), we make an AA query on instructions in bar(), which have MMOs
with IR Values in bar()
4. CFL-AA is reached and does not have a cached graph for bar(), so it builds
one
5. While building the graph for bar(), it reaches the call to foo(), and calls
tryInterproceduralAnalysis
6. CFL-AA does not have a cached graph for foo(), so tryInterproceduralAnalysis
triggers one to be constructed
7. But foo() is now empty, and so has trivial aliasing properties 
8. We return an incorrect AA result when compiling bar() 

-Hal 
> -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
> > 
> 
-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/c0586b31/attachment.html>

> On May 12, 2016, at 4:11 PM, Chandler Carruth <chandlerc at
gmail.com> wrote:
> 
> FWIW, +1 from me as well.
Cool.  Thanks Chandler.
> 
> 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.
Yeah, no need for a pass unless we really want it.  I could, for example, just
delete the function bodies in the AsmPrinter once we’re done with them.  Will
see how that looks and get started on a patch and actual review
thread.
> 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.
Sounds good.  I never considered removing the contents of the BBs too, but thats
a good idea.

Cheers,
Pete
> 
> -Chandler
> 
> On Tue, Mar 8, 2016 at 1:16 PM Quentin Colombet <qcolombet at apple.com
<mailto:qcolombet at apple.com>> wrote:
>> On Mar 8, 2016, at 11:50 AM, Eric Christopher <echristo at gmail.com
<mailto: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
<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/9f43c7c0/attachment.html>