[llvm-commits] [PATCH] Make SimplifyCFGPass preserve the dominator tree

[Peter Cooper]

On Jun 8, 2012, at 3:07 PM, Chandler Carruth wrote:

> On Fri, Jun 8, 2012 at 3:04 PM, Peter Cooper <peter_cooper at apple.com> wrote:
> 
> On Jun 8, 2012, at 3:00 PM, Chandler Carruth wrote:
> 
>> On Fri, Jun 8, 2012 at 10:47 AM, Peter Cooper <peter_cooper at apple.com> wrote:
>> Hi all
>> 
>> Attached is a pass to make the SimplifyCFGPass preserve the dominator tree.  Currently we see lots of recalculations of the dom tree right after simplify cfg runs, regardless of whether simplify cfg actually did anything.
>> 
>> This pass explicitly recalculates the dom tree if simplify cfg did anything, but otherwise just leaves it preserved so we recalculate less often.
>> 
>> Also, i'm open to suggestions for a better way to do this.  Ideally the pass manager could track this but not all passes return true from their run functions when they actually make a change.
>> 
>> Can we just go fix these passes and then teach the pass manager to preserve analyses across passes that claim they didn't change anything? There aren't *that* many optimization passes.
> Yeah, that would be possible.  Like you say, there aren't that many passes.  As I just replied to John, passes like simplify lib calls need fixed but its trivial to see how its return value would need to be fixed.
> 
> The fact that the semantic impact of the return is being ignored by passes is pretty annoying.
> 
> I'm quite tempted to suggest a basic check-summing system that can be run like the verifier before and after a pass by the pass manager to assert that in fact the pass didn't modify stuff.... Bit of a yak shave, but maybe something to leave FIXMEs or comments about. It would be good to have the pass manager enforce this eventually.
That would be great.  Common data structures such as the CFG should be easy enough to reason about whether they have been changed.  Actually, for many of our analysis passes it is just the CFG thats interesting in terms of updates so just covering it with your checksum solution would get us quite far here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120608/56334aa4/attachment.html>