forked from OSchip/llvm-project
dd2e275a47
pass. The original logic only considered direct successors of the hoisted domtree nodes, but that isn't really enough. If there are other basic blocks that are completely within the subtree, their successors could just as easily be impacted by the hoisting. The more I think about it, the more I think the correct update here is to hoist every block on the dominance frontier which has an idom in the chain we hoist across. However, this is subtle enough that I'd definitely appreciate some more eyes on it. Sadly, if this is the correct algorithm, it requires computing a (highly localized) dominance frontier. I've done this in the simplest (IE, least code) way I could come up with, but that may be too naive. Suggestions welcome here, dominance update algorithms are not an area I've studied much, so I don't have strong opinions. In good news, with this patch, turning on simple unswitch passes the LLVM test suite for me with asserts enabled. Differential Revision: https://reviews.llvm.org/D32740 llvm-svn: 303843 |
||
|---|---|---|
| .. | ||
| 2006-06-13-SingleEntryPHI.ll | ||
| 2006-06-27-DeadSwitchCase.ll | ||
| 2007-05-09-Unreachable.ll | ||
| 2007-05-09-tl.ll | ||
| 2007-07-12-ExitDomInfo.ll | ||
| 2007-07-13-DomInfo.ll | ||
| 2007-07-18-DomInfo.ll | ||
| 2007-08-01-Dom.ll | ||
| 2007-08-01-LCSSA.ll | ||
| 2007-10-04-DomFrontier.ll | ||
| 2008-06-02-DomInfo.ll | ||
| 2008-06-17-DomFrontier.ll | ||
| 2010-11-18-LCSSA.ll | ||
| 2011-06-02-CritSwitch.ll | ||
| 2011-09-26-EHCrash.ll | ||
| 2012-04-02-IndirectBr.ll | ||
| 2012-04-30-LoopUnswitch-LPad-Crash.ll | ||
| 2012-05-20-Phi.ll | ||
| 2015-09-18-Addrspace.ll | ||
| LIV-loop-condtion.ll | ||
| basictest.ll | ||
| cleanuppad.ll | ||
| copy-metadata.ll | ||
| crash.ll | ||
| exponential-behavior.ll | ||
| infinite-loop.ll | ||
| msan.ll | ||
| preserve-analyses.ll | ||
| trivial-unswitch.ll | ||