summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils/LoopUnroll.cpp
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2014-02-26 03:14:14 +0000
committerChandler Carruth <chandlerc@gmail.com>2014-02-26 03:14:14 +0000
commit6aedc106bab1c9a98a5e148bbab611249ea0c245 (patch)
tree76689fab7457f43b92d6cc344c6a7a351ceb8d34 /llvm/lib/Transforms/Utils/LoopUnroll.cpp
parenta170f081092b7d1ad966e5cc57c0b18a54778642 (diff)
downloadbcm5719-llvm-6aedc106bab1c9a98a5e148bbab611249ea0c245.tar.gz
bcm5719-llvm-6aedc106bab1c9a98a5e148bbab611249ea0c245.zip
[SROA] Fix PR18615 with some long overdue simplifications to the bounds
checking in SROA. The primary change is to just rely on uge for checking that the offset is within the allocation size. This removes the explicit checks against isNegative which were terribly error prone (including the reversed logic that led to PR18615) and prevented us from supporting stack allocations larger than half the address space.... Ok, so maybe the latter isn't *common* but it's a silly restriction to have. Also, we used to try to support a PHI node which loaded from before the start of the allocation if any of the loaded bytes were within the allocation. This doesn't make any sense, we have never really supported loading or storing *before* the allocation starts. The simplified logic just doesn't care. We continue to allow loading past the end of the allocation in part to support cases where there is a PHI and some loads are larger than others and the larger ones reach past the end of the allocation. We could solve this a different and more conservative way, but I'm still somewhat paranoid about this. llvm-svn: 202224
Diffstat (limited to 'llvm/lib/Transforms/Utils/LoopUnroll.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud