Hal Finkel via llvm-dev
2016-May-12 23:32 UTC
[llvm-dev] Deleting function IR after codegen
----- 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>
Pete Cooper via llvm-dev
2016-May-12 23:39 UTC
[llvm-dev] Deleting function IR after codegen
> On May 12, 2016, at 4:32 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > 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()Hmm. This is an interesting use case. Is this even legal in the current pass manager? Codegen is a FunctionPass which I thought could only look at global variables and its own function. Or is the rule that a FunctionPass has read/write access to its own function, but read-only to other functions which is effectively what you’d need for the CFL-AA case above? Cheers, Pete> > -Hal > > -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 > > > > > -- > 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/35a30a02/attachment.html>
Hal Finkel via llvm-dev
2016-May-12 23:52 UTC
[llvm-dev] Deleting function IR after codegen
----- Original Message -----> From: "Pete Cooper" <peter_cooper at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Duncan P. N. Exon > Smith" <dexonsmith at apple.com>, "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>, "Quentin Colombet" <qcolombet at apple.com>, > "Eric Christopher" <echristo at gmail.com> > Sent: Thursday, May 12, 2016 6:39:25 PM > Subject: Re: [llvm-dev] Deleting function IR after codegen> > On May 12, 2016, at 4:32 PM, Hal Finkel < hfinkel at anl.gov > wrote: >> > ----- 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() >> Hmm. This is an interesting use case. Is this even legal in the > current pass manager? Codegen is a FunctionPass which I thought > could only look at global variables and its own function.> Or is the rule that a FunctionPass has read/write access to its own > function, but read-only to other functions which is effectively what > you’d need for the CFL-AA case above?I believe that, technically speaking, this is not legal. CFL-AA should really be a module pass if it wants to do IPA. I think that, at the time it was originally developed, it was made a function pass so that it could work without modifying every other function pass in the pipeline to mark it as preserved. Of course, we later did this anyway for GlobalsAA (a module-level analysis), so we should probably go back and do the same for CFL-AA. I'm not sure that's the important distinction, however. GlobalsAA pre-computes all necessary data for the module up front (when runOnModule is called), so the scenario I described has no analogy there. If GlobalsAA computed information on Globals lazily (like CFL-AA builds function graphs lazily), it would have the same problem. I'm not claiming that this is a good thing, I just wanted to point out that it can be a problem given code we have in-tree now. -Hal> Cheers, > Pete> > -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 >-- 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/859e253c/attachment.html>