Merging r195118:
------------------------------------------------------------------------
r195118 | chandlerc | 2013-11-19 01:03:18 -0800 (Tue, 19 Nov 2013) | 22 lines

Fix an issue where SROA computed different results based on the relative
order of slices of the alloca which have exactly the same size and other
properties. This was found by a perniciously unstable sort
implementation used to flush out buggy uses of the algorithm.

The fundamental idea is that findCommonType should return the best
common type it can find across all of the slices in the range. There
were two bugs here previously:

1) We would accept an integer type smaller than a byte-width multiple,
   and if there were different bit-width integer types, we would accept
   the first one. This caused an actual failure in the testcase updated
   here when the sort order changed.
2) If we found a bad combination of types or a non-load, non-store use
   before an integer typed load or store we would bail, but if we found
   the integere typed load or store, we would use it. The correct
   behavior is to always use an integer typed operation which covers the
   partition if one exists.

While a clever debugging sort algorithm found problem #1 in our existing
test cases, I have no useful test case ideas for #2. I spotted in by
inspection when looking at this code.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195217 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r195129:
------------------------------------------------------------------------
r195129 | mcinally | 2013-11-19 06:36:00 -0800 (Tue, 19 Nov 2013) | 2 lines

Fix assembly operands for the SSE2 cvtsd2ss instruction.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195218 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r195138:
------------------------------------------------------------------------
r195138 | atrick | 2013-11-19 10:29:45 -0800 (Tue, 19 Nov 2013) | 3 lines

Obvious pasto survived a couple rounds of cleanup.

Caught by Aaron Ballman.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195219 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r195152:
------------------------------------------------------------------------
r195152 | jacksprat | 2013-11-19 12:53:28 -0800 (Tue, 19 Nov 2013) | 1 line

reverts 195057 per request
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195220 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r195161:
------------------------------------------------------------------------
r195161 | arnolds | 2013-11-19 14:20:18 -0800 (Tue, 19 Nov 2013) | 1 line

SLPVectorizer: Fix whitespace errors
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195221 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r195162:
------------------------------------------------------------------------
r195162 | arnolds | 2013-11-19 14:20:20 -0800 (Tue, 19 Nov 2013) | 12 lines

SLPVectorizer: Fix stale for Value pointer array

We are slicing an array of Value pointers and process those slices in a loop.
The problem is that we might invalidate a later slice by vectorizing a former
slice.

Use a WeakVH to track the pointer. If the pointer is deleted or RAUW'ed we can
tell.

The test case will only fail when running with libgmalloc.

radar://15498655
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195222 91177308-0d34-0410-b5e6-96231b3b80d8