This is meant to be used when testing dot releases e.g.:

./test-release -release 3.3 -dot 1 -rc 1

llvm-svn: 190581

llvm-svn: 190580

This should hopefully fix
http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32

Merged from r182446
Author: Rafael Espindola <rafael.espindola@gmail.com>
Date:   Wed May 22 02:30:47 2013 +0000

llvm-svn: 190579

in functions which call __builtin_unwind_init()

__builtin_unwind_init() is an undocumented gcc intrinsic which has this effect,
and is used in libgcc_eh.

Goes part of the way toward fixing PR8541.

Merged from r183984
Author: Derek Schuff <dschuff@google.com>
Date:   Fri Jun 14 16:15:29 2013 +0000

llvm-svn: 190578

llvm-svn: 190577

When a function is inlined we lazily construct the variables
representing the function's parameters. After that, we add any remaining
unused parameters.

If the function doesn't use all the parameters, or uses them out of
order, then the DWARF would produce them in that order, producing a
parameter order that doesn't match the source.

This fix causes us to always keep the arg variables at the start of the
variable list & in the original order from the source.

Merged from r183297
Author: David Blaikie <dblaikie@gmail.com>
Date:   Wed Jun 5 05:39:59 2013 +0000

llvm-svn: 186678

Merged from r182190
Author: Tim Northover <t.p.northover@gmail.com>
Date:   Sat May 18 08:17:47 2013 +0000

llvm-svn: 186677

succession. Fixes PR16363.

Merged from r184240
Author: Eli Friedman <eli.friedman@gmail.com>
Date:   Tue Jun 18 21:33:38 2013 +0000

llvm-svn: 186204

vectorizing loops with memory accesses to non-zero address spaces. It
simply dropped the AS info. Fixes PR16306.


Merged from r184103
Author: Pekka Jaaskelainen <pekka.jaaskelainen@tut.fi>
Date:   Mon Jun 17 18:49:06 2013 +0000

llvm-svn: 185869

Patch by: Vincent Lejeune

https://bugs.freedesktop.org/show_bug.cgi?id=64877

NOTE: This is a candidate for the 3.3 branch.


Merged from r182600
Author: Tom Stellard <thomas.stellard@amd.com>
Date:   Thu May 23 18:26:42 2013 +0000

llvm-svn: 185868

llvm-svn: 184287

- Also split out a section on build portability and updated the list of features and improvements.
--- This now reflects the up-coming merge of patches from trunk into the release_33 branch.

llvm-svn: 183554

llvm-svn: 183500

llvm-svn: 183396

llvm-svn: 183386

The original test case showed a problem with the independet blocks pass and
we decided to XFAIL it for now. Unfortunately the failure is not detected if
we build without asserts and the verification of the independent block pass
is not run. This change tests now for the actual reason of the failure and
should trigger even in a non asserts build. We did not yet solve the underlying
bug, but this should at least make the test suite behavior consistent.

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@183025

llvm-svn: 183384

to be able to compile with ISL master as of today
1df91d8515ec88dc7f7f597168ad0f34f26de5a7

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@183023

llvm-svn: 183383

to detect scops in functions with no loops, use -polly-detect-scops-in-functions-without-loops

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182941

llvm-svn: 183382

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182662

llvm-svn: 183381

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182661

llvm-svn: 183380

In GDB when "step" through generateScalarLoad and "finish" the call, the
returned value is non NULL, however when printing the value contained in
BBMap[Load] after this stmt:

  BBMap[Load] = generateScalarLoad(...);

the value in BBMap[Load] is NULL, and the BBMap.count(Load) is 1.

The only intuitive idea that I have to explain this behavior is that we are
playing with the undefined behavior of eval order of the params for the function
standing for "BBMap[Load] = generateScalarLoad()". "BBMap[Load] = " may be
executed before generateScalarLoad is called.

Here are some other possible explanations from Will Dietz <w@wdtz.org>:

The error is likely due to BBMap[Load] being evaluated first (creating
a {Load -> uninitialized } entry in the DenseMap), then
generateScalarLoad eventually accesses the same element and finds it
to be NULL (DenseMap[Old])..  Offhand I'm not sure if this is
guaranteed to be NULL or if it's uninitialized and happens to be NULL.

The same issue can also go wrong in an even worse way: the second
DenseMap access can trigger a rehash and *invalidate* the an earlier
evaluated expression (for example LHS of the assignment), leading to a
crash when performing the assignment store.

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182655

llvm-svn: 183379

It was initially committed to allow people to get a list of the files used
or generated in the matmul tutorial. Since the documentation does now
point people to the directory in their git checkout, it is not necessary anymore
to make a directory listing available. Especially, as this never worked and
recently the LLVM web server does not deliver files in this directory at all
due to the unsupported .htaccess file.

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182370

llvm-svn: 183378

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182310

llvm-svn: 183377

As the namings of the scops have changed, polly was not able to read in the user
given .jscop files. By renaming the provided files, polly now finds them again
and can use them to optimize the matmul function. We also update the generated
files to reflect the very latest version of Polly.

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182265

llvm-svn: 183376

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182171

llvm-svn: 183375

When the Polly code generation was written we did not correctly update the
LoopInfo data, but still claimed that the loop information is correct. This
does not only lead to missed optimizations, but it can also cause
miscompilations in case passes such as LoopSimplify are run after Polly.

Reported-by: Sergei Larin <slarin@codeaurora.org>

Merged from: https://llvm.org/svn/llvm-project/polly/trunk@181987

llvm-svn: 183374

                BeforeBB
                   |
                   v
                GuardBB
                /      \
       __  PreHeaderBB  \
      /  \    /         |
   latch  HeaderBB      |
      \  /    \         /
       <       \       /
                \     /
                ExitBB

This does not only remove the need for an explicit loop rotate pass, but it also
gives us the possibility to skip the construction of the guard condition in case
the loop is known to be executed at least once. We do not yet exploit this, but
by implementing this analysis in the isl code generator we should be able to
remove more guards than the generic loop rotate pass can.  Another point is that
loop rotation can introduce additional PHI nodes, which may hide that a loop can
be executed in parallel. This change avoids this complication and will make it
easier to move the openmp code generation into a separate pass.

Merged from https://llvm.org/svn/llvm-project/polly/trunk@181986

llvm-svn: 183373

llvm-svn: 183249

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

llvm-svn: 183246

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

llvm-svn: 183245

llvm-svn: 183212

llvm-svn: 183208

llvm-svn: 183207

------------------------------------------------------------------------
r183153 | dmalea | 2013-06-03 13:45:54 -0700 (Mon, 03 Jun 2013) | 7 lines

Fix crash (in optimized builds) due to invalid metadata operand
- ConstantDataArray is not a valid MDNode operand
- encode function-name strings in metadata by wrapping in an MDString instead

- should resolve reported by http://llvm-jenkins.debian.net/job/llvm-toolchain-quantal-binaries/architecture=amd64,distribution=quantal/173/


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

llvm-svn: 183191

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

llvm-svn: 183190

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

llvm-svn: 183189

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

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

llvm-svn: 183181

Improve support for compiler-rt tests in CMake build.

Now compiler-rt tests run correctly if compiler-rt is checked out into
arbitrary directory (not necessarily projects/compiler-rt).
Patch by Greg Fitzgerald!

llvm-svn: 183180

    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/trunk@183060 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-svn: 183066

    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/trunk@182989 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-svn: 183013