summaryrefslogtreecommitdiffstats
path: root/clang
diff options
context:
space:
mode:
authorAndrew Trick <atrick@apple.com>2012-06-20 05:23:33 +0000
committerAndrew Trick <atrick@apple.com>2012-06-20 05:23:33 +0000
commitff2ed7b6872a8c0888ac16d0931b353a0bda95f4 (patch)
tree1cbbc2101073159ee6740dec8812c59f934363a5 /clang
parent74ede098b378730e73c3df9c75b5418f7852ab25 (diff)
downloadbcm5719-llvm-ff2ed7b6872a8c0888ac16d0931b353a0bda95f4.tar.gz
bcm5719-llvm-ff2ed7b6872a8c0888ac16d0931b353a0bda95f4.zip
A new algorithm for computing LoopInfo. Temporarily disabled.
-stable-loops enables a new algorithm for generating the Loop forest. It differs from the original algorithm in a few respects: - Not determined by use-list order. - Initially guarantees RPO order of block and subloops. - Linear in the number of CFG edges. - Nonrecursive. I didn't want to change the LoopInfo API yet, so the block lists are still inclusive. This seems strange to me, and it means that building LoopInfo is not strictly linear, but it may not be a problem in practice. At least the block lists start out in RPO order now. In the future we may add an attribute or wrapper analysis that allows other passes to assume RPO order. The primary motivation of this work was not to optimize LoopInfo, but to allow reproducing performance issues by decomposing the compilation stages. I'm often unable to do this with the current LoopInfo, because the loop tree order determines Loop pass order. Serializing the IR tends to invert the order, which reverses the optimization order. This makes it nearly impossible to debug interdependent loop optimizations such as LSR. I also believe this will provide more stable performance results across time. llvm-svn: 158790
Diffstat (limited to 'clang')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud