summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/source-manager/TestSourceManager.py
diff options
context:
space:
mode:
authorPhilip Reames <listmail@philipreames.com>2016-03-03 00:01:42 +0000
committerPhilip Reames <listmail@philipreames.com>2016-03-03 00:01:42 +0000
commit23d933982a4465dc527c5a9635be6aea13e43e03 (patch)
treec91bb189c8363491434130ad5a2fedca4552af99 /lldb/packages/Python/lldbsuite/test/source-manager/TestSourceManager.py
parent1ef654024f490b403494265c968570ca6bd800f3 (diff)
downloadbcm5719-llvm-23d933982a4465dc527c5a9635be6aea13e43e03.tar.gz
bcm5719-llvm-23d933982a4465dc527c5a9635be6aea13e43e03.zip
[MBP] Avoid placing random blocks between loop preheader and header
If we have a loop with a rarely taken path, we will prune that from the blocks which get added as part of the loop chain. The problem is that we weren't then recognizing the loop chain as schedulable when considering the preheader when forming the function chain. We'd then fall to various non-predecessors before finally scheduling the loop chain (as if the CFG was unnatural.) The net result was that there could be lots of garbage between a loop preheader and the loop, even though we could have directly fallen into the loop. It also meant we separated hot code with regions of colder code. The particular reason for the rejection of the loop chain was that we were scanning predecessor of the header, seeing the backedge, believing that was a globally more important predecessor (true), but forgetting to account for the fact the backedge precessor was already part of the existing loop chain (oops!. Differential Revision: http://reviews.llvm.org/D17830 llvm-svn: 262547
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/source-manager/TestSourceManager.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud