[InstCombine] Change LLVM To canonicalize toward the value type being
authorChandler Carruth <chandlerc@gmail.com>
Tue, 25 Nov 2014 10:09:51 +0000 (10:09 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Tue, 25 Nov 2014 10:09:51 +0000 (10:09 +0000)
commit333d5c9f518ee5e3a33f48be5fee2d2eaf8c8978
tree18107e2ec86aa2f93c46c22f1630fd0f317004b2
parent0ab565a2754002fc32894254d4e986c26f433e42
[InstCombine] Change LLVM To canonicalize toward the value type being
stored rather than the pointer type.

This change is analogous to r220138 which changed the canonicalization
for loads. The rationale is the same: memory does not have a type,
operations (and thus the values they produce) have a type. We should
match that type as closely as possible rather than reading some form of
semantics into the pointer type.

With this change, loads and stores should no longer be made with
nonsensical types for the values that tehy load and store. This is
particularly important when trying to match specific loaded and stored
types in the process of doing other instcombines, which is what led me
down this twisty maze of miscanonicalization.

I've put quite some effort into looking through IR to find places where
LLVM's optimizer was being unreasonably conservative in the face of
mismatched load and store types, however it is possible (let's say,
likely!) I have missed some. If you see regressions here, or from
r220138, the likely cause is some part of LLVM failing to cope with load
and store types differing. Test cases appreciated, it is important that
we root all of these out of LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222748 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
test/Transforms/InstCombine/2011-06-13-nsw-alloca.ll
test/Transforms/InstCombine/bitcast-alias-function.ll
test/Transforms/InstCombine/bitcast-store.ll
test/Transforms/InstCombine/cast.ll
test/Transforms/InstCombine/getelementptr.ll
test/Transforms/InstCombine/select.ll