[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)
commit816d26fe5eeae4adcb0ceda05884747e15f55bb2
tree1498c5627960a4434dec743738f9f68748e439e3
parenta98b7b01be4a2d6138c8b9a054e73bea98efa06e
[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.

llvm-svn: 222748
llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
llvm/test/Transforms/InstCombine/2011-06-13-nsw-alloca.ll
llvm/test/Transforms/InstCombine/bitcast-alias-function.ll
llvm/test/Transforms/InstCombine/bitcast-store.ll
llvm/test/Transforms/InstCombine/cast.ll
llvm/test/Transforms/InstCombine/getelementptr.ll
llvm/test/Transforms/InstCombine/select.ll