summaryrefslogtreecommitdiff
path: root/lib/ExecutionEngine/RuntimeDyld
diff options
context:
space:
mode:
authorHal Finkel <hfinkel@anl.gov>2014-05-07 22:25:18 +0000
committerHal Finkel <hfinkel@anl.gov>2014-05-07 22:25:18 +0000
commitdf60e43e05e1a61f1c9f7039ae9f7054bba570ea (patch)
tree1e92096450c38d8f521db2d4c2faeb11c91dfa2d /lib/ExecutionEngine/RuntimeDyld
parentf7659e715fc9662e6fe1fddb4eaa50d18c1f3c6d (diff)
downloadllvm-df60e43e05e1a61f1c9f7039ae9f7054bba570ea.tar.gz
llvm-df60e43e05e1a61f1c9f7039ae9f7054bba570ea.tar.bz2
llvm-df60e43e05e1a61f1c9f7039ae9f7054bba570ea.tar.xz
[X86TTI] Remove the unrolling branch limits
The loop stream detector (LSD) on modern Intel cores, which optimizes the execution of small loops, has limits on the number of taken branches in addition to uop-count limits (modern AMD cores have similar limits). Unfortunately, at the IR level, estimating the number of branches that will be taken is difficult. For one thing, it strongly depends on later passes (block placement, etc.). The original implementation took a conservative approach and limited the maximal BB DFS depth of the loop. However, fairly-extensive benchmarking by several of us has revealed that this is the wrong approach. In fact, there are zero known cases where the branch limit prevents a detrimental unrolling (but plenty of cases where it does prevent beneficial unrolling). While we could improve the current branch counting logic by incorporating branch probabilities, this further complication seems unjustified without a motivating regression. Instead, unless and until a regression appears, the branch counting will be removed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208255 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/ExecutionEngine/RuntimeDyld')
0 files changed, 0 insertions, 0 deletions