Closed llvmbot closed 15 years ago
It probably doesn't... owen?
Okay... so then the question remains: why does ADCE need to be able to deal with this?
Right, I was thinking of the function... you're right though that the pass is what really matters.
I just realized that we might not have been talking about the same thing, since simplifycfg can refer to both the SimplifyCFG function and the "simplifycfg" pass (whose full name is CFGSimplifyPass).
simplifycfg deletes blocks with no predecessors. If you have a cyclic subgraph of the cfg that is not reachable, simplifycfg won't touch it.
That's simply wrong; see RemoveUnreachableBlocks and MarkAliveBlocks in SimplifyCFGPass.cpp.
simplifycfg deletes blocks with no predecessors. If you have a cyclic subgraph of the cfg that is not reachable, simplifycfg won't touch it.
I don't follow why "part 1" is necessary; SimplifyCFG already prunes unreachable blocks.
Part 1 is done as of r53038.
Part 2 is done as of r53032.
Owen was going to take a look at this :)
The problem is that this is producing a cyclic structure with multiple blocks that are unreachable, all of which have preds.
We should do two things:
1) the ADCE pass should do a mark and sweep pass to nuke unreachable blocks 2) GVN should be improved to not be pessimized by unreachable blocks (using 'undef' as an available version of any expression from the unreachable block).
Right, that's what I meant.
Jump threading naturally kills blocks... maybe it should remove the dead blocks using something like the RemoveUnreachableBlocks code in SimplifyCFG.
Extended Description
In the case attached, jump threading produces output with unreachable blocks that still branch to reachable blocks. It would be really nice if it didn't do this. This situation causes GVN to miss some optimizations.