summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/StringExtras.cpp
diff options
context:
space:
mode:
authorPhilip Reames <listmail@philipreames.com>2019-06-20 18:45:06 +0000
committerPhilip Reames <listmail@philipreames.com>2019-06-20 18:45:06 +0000
commita7fd8a806f005042debfaccd331ef06b413b5ad1 (patch)
treef749e2375c5761d93238433b4ada198fcf24eab9 /llvm/lib/Support/StringExtras.cpp
parent678e19d80c2a048ccb6d9d38cb3ab63a6c09470c (diff)
downloadbcm5719-llvm-a7fd8a806f005042debfaccd331ef06b413b5ad1.tar.gz
bcm5719-llvm-a7fd8a806f005042debfaccd331ef06b413b5ad1.zip
[LFTR] Fix a (latent?) bug related to nested loops
I can't actually come up with a test case this triggers on without an out of tree change, but in theory, it's a bug in the recently added multiple exit LFTR support. The root issue is that an exiting block common to two loops can (in theory) have computable exit counts for both loops. Rewriting the exit of an inner loop in terms of the outer loops IV would cause the inner loop to either a) run forever, or b) terminate on the first iteration. In practice, we appear to get lucky and not have the exit count computable for the outer loop, except when it's trivially zero. Given we bail on zero exit counts, we don't appear to ever trigger this. But I can't come up with a reason we *can't* compute an exit count for the outer loop on the common exiting block, so this may very well be triggering in some cases. llvm-svn: 363964
Diffstat (limited to 'llvm/lib/Support/StringExtras.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud