Merging r200201:

------------------------------------------------------------------------
r200201 | stpworld | 2014-01-27 04:18:31 -0500 (Mon, 27 Jan 2014) | 31 lines

Fix for PR18102.

Issue outcomes from DAGCombiner::MergeConsequtiveStores, more precisely from
mem-ops sequence sorting.

Consider, how MergeConsequtiveStores works for next example:

store i8 1, a[0]
store i8 2, a[1]
store i8 3, a[1]   ; a[1] again.
return   ; DAG starts here

1. Method will collect all the 3 stores.
2. It sorts them by distance from the base pointer (farthest with highest
index).
3. It takes first consecutive non-overlapping stores and (if possible) replaces
them with a single store instruction.

The point is, we can't determine here which 'store' instruction
would be the second after sorting ('store 2' or 'store 3').
It happens that 'store 3' would be the second, and 'store 2' would be the third.

So after merging we have the next result:

store i16 (1 | 3 << 8), base   ; is a[0] but bit-casted to i16
store i8 2, a[1]

So actually we swapped 'store 3' and 'store 2' and got wrong contents in a[1].

Fix: In sort routine just also take into account mem-op sequence number.

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

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

------------------------------------------------------------------------
r200202 | stpworld | 2014-01-27 04:43:10 -0500 (Mon, 27 Jan 2014) | 2 lines

Additional fix for 200201: due to dependence on bitwidth test was moved to X86 directory.

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

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

------------------------------------------------------------------------
r205738 | atrick | 2014-04-07 17:29:22 -0400 (Mon, 07 Apr 2014) | 16 lines

Put a limit on ScheduleDAGSDNodes::ClusterNeighboringLoads to avoid blowing up compile time.

Fixes PR16365 - Extremely slow compilation in -O1 and -O2.

The SD scheduler has a quadratic implementation of load clustering
which absolutely blows up compile time for large blocks with constant
pool loads. The MI scheduler has a better implementation of load
clustering. However, we have not done the work yet to completely
eliminate the SD scheduler. Some benchmarks still seem to benefit from
early load clustering, although maybe by chance.

As an intermediate term fix, I just put a nice limit on the number of
DAG users to search before finding a match. With this limit there are no
binary differences in the LLVM test suite, and the PR16365 test case
does not suffer any compile time impact from this routine.

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

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