summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/StackSlotColoring.cpp
diff options
context:
space:
mode:
authorPete Cooper <peter_cooper@apple.com>2016-05-27 17:06:50 +0000
committerPete Cooper <peter_cooper@apple.com>2016-05-27 17:06:50 +0000
commit34a7a945b0591c6f0ee9f84646a2b080c2313da9 (patch)
tree2194e67a023f8692c2726c9e8c3ae6e53e2d918a /llvm/lib/CodeGen/StackSlotColoring.cpp
parent32b4d15e0a8a059ec4b350ccd2c506bd870f46e1 (diff)
downloadbcm5719-llvm-34a7a945b0591c6f0ee9f84646a2b080c2313da9.tar.gz
bcm5719-llvm-34a7a945b0591c6f0ee9f84646a2b080c2313da9.zip
Don't generate unnecessary signed ConstantRange during multiply. NFC
r231483 taught ConstantRange::multiply to be clever about signed vs unsigned ranges. For example, an unsigned range could be full-set while the signed range is more specific than that. In looking at the allocations trace for LTO'ing verify-uselistorder (see r236629 for details), millions of allocations are from APInt, many of which come from ConstantRange's. This change tries to avoid some (3.2 million) allocations by returning the unsigned range if its suitable. The checks here are that it should not be a wrapping range, and should be positive. That should be enough to check for ranges such as [1, 10) which the signed range will be equal to, if we were to calculate it. Differential Revision: http://reviews.llvm.org/D20723 Reviewed by James Molloy llvm-svn: 271020
Diffstat (limited to 'llvm/lib/CodeGen/StackSlotColoring.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud