Merging r183108:
------------------------------------------------------------------------
r183108 | vljn | 2013-06-03 08:44:42 -0700 (Mon, 03 Jun 2013) | 1 line

R600: CALL_FS consumes a stack size entry
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@183181 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r183035:
------------------------------------------------------------------------
r183035 | arnolds | 2013-05-31 12:53:50 -0700 (Fri, 31 May 2013) | 7 lines

LoopVectorize: PHIs with only outside users should prevent vectorization

We check that instructions in the loop don't have outside users (except if
they are reduction values). Unfortunately, we skipped this check for
if-convertable PHIs.

Fixes PR16184.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@183189 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r181909:
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@183190 91177308-0d34-0410-b5e6-96231b3b80d8
Update the release notes for the 3.3 release.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@183207 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r182989:
------------------------------------------------------------------------
r182989 | atrick | 2013-05-30 23:43:25 -0700 (Thu, 30 May 2013) | 13 lines

Fix ScalarEvolution::ComputeExitLimitFromCond for 'or' conditions.

Fixes PR16130 - clang produces incorrect code with loop/expression at -O2.

This is a 2+ year old bug that's now holding up the release. It's a
case where we knowingly made aggressive assumptions about undefined
behavior. These assumptions are wrong when SCEV is computing a
subexpression that does not directly control the branch. With this
fix, we avoid making assumptions in those cases but still optimize the
common case. SCEV's trip count computation for exits controlled by
'or' expressions is now analagous to the trip count computation for
loops with multiple exits. I had already fixed the multiple exit case
to be conservative.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@183245 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r183060:
------------------------------------------------------------------------
r183060 | atrick | 2013-05-31 16:34:46 -0700 (Fri, 31 May 2013) | 11 lines

Prevent loop-unroll from making assumptions about undefined behavior.

Fixes rdar:14036816, PR16130.

There is an opportunity to compute precise trip counts for 'or'
expressions and multi-exit loops.
rdar:14038809: Optimize trip count computation for multi-exit loops.

To do this we need to record the fact that ExitLimit assumes NSW. When
it does not we can safely assume that the loop trip count is the
minimum ExitLimt across all subexpressions and loop exits.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@183246 91177308-0d34-0410-b5e6-96231b3b80d8
Update release notes for mips.

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