summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2015-01-22 05:08:12 +0000
committerChandler Carruth <chandlerc@gmail.com>2015-01-22 05:08:12 +0000
commitcd8522ef44d083b611b2b78f261b4f7711381689 (patch)
treed4ce4cfb44a3a198d512ebfe6e65af266af4374b /llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp
parent36e1ddfd13aa74dc7d283a3844933e9605498eeb (diff)
downloadbcm5719-llvm-cd8522ef44d083b611b2b78f261b4f7711381689.tar.gz
bcm5719-llvm-cd8522ef44d083b611b2b78f261b4f7711381689.zip
[canonicalize] Teach InstCombine to canonicalize loads which are only
ever stored to always use a legal integer type if one is available. Regardless of whether this particular type is good or bad, it ensures we don't get weird differences in generated code (and resulting performance) from "equivalent" patterns that happen to end up using a slightly different type. After some discussion on llvmdev it seems everyone generally likes this canonicalization. However, there may be some parts of LLVM that handle it poorly and need to be fixed. I have at least verified that this doesn't impede GVN and instcombine's store-to-load forwarding powers in any obvious cases. Subtle cases are exactly what we need te flush out if they remain. Also note that this IR pattern should already be hitting LLVM from Clang at least because it is exactly the IR which would be produced if you used memcpy to copy a pointer or floating point between memory instead of a variable. llvm-svn: 226781
Diffstat (limited to 'llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud