[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
[mips][micromips] Use call instructions with short delay slots
Differential Revision: http://reviews.llvm.org/D6338


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222752 91177308-0d34-0410-b5e6-96231b3b80d8
Revert r222746: That commit did not update any tests and caused two R600
tests to start failing.

Original commit log: R600/SI: Disable commutativity for MIN/MAX_LEGACY

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222753 91177308-0d34-0410-b5e6-96231b3b80d8