llvm-svn: 249287

llvm-svn: 249286

llvm-svn: 249285

llvm-svn: 249284

The target "check-clang-tools" is affected by CLANG_INCLUDE_TESTS but it was undefined in 1st configuration procedure.

llvm-svn: 249283

when building a module.

llvm-svn: 249282

Summary: When LLVM/Clang is built without ARM support, the ios_kext runtime
library is not built, but without this patch, the Makefile still tries to
copy it. This is a recent regression, because the ios_kext library used
to also be built on x86_64.

Reviewers: beanz

Subscribers: aemerson, cfe-commits, rengolin

Differential Revision: http://reviews.llvm.org/D13421

llvm-svn: 249281

We already check for LandingPadInst two lines above.

llvm-svn: 249280

In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes.  It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure).  There is a
desire to support __declspec in Playstation code, and possibly other
environments.  This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword.  Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.

Patch by Warren Ristow!

llvm-svn: 249279

llvm-svn: 249278

llvm-svn: 249277

  A statement with an empty domain complicates the invariant load
  hoisting and does not help any subsequent analysis or transformation.
  In fact it might introduce parameter dimensions or increase the
  schedule dimensionality. To this end, we remove statements with an
  empty domain early in the SCoP simplification.

llvm-svn: 249276

llvm-svn: 249275

  The "unprofitable" heuristic was broken and counted boxed loops
  even though we do not represent and optimize them.

llvm-svn: 249274

  Before isValidCFG() could hide the fact that a loop is non-affine by
  over-approximation. This is problematic if a subregion of the loop contains
  an exit/latch block and is over-approximated. Now we do not over-approximate
  in the isValidCFG function if we check loop control.  If such control is
  non-affine the whole loop is over-approximated, not only a subregion.

llvm-svn: 249273

  This patch cannot be tested on its own as the isValidCFG currently
  hides the fact that control is actually non-affine with
  over-approximation. This will be corrected in the next patch and a
  test for non-affine latches will be added.

llvm-svn: 249272

llvm-svn: 249271

Summary:
The bitcode format is described in this document:
  https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
For more info on ThinLTO see:
  https://sites.google.com/site/llvmthinlto

The first customer is ThinLTO, however the data structures are designed
and named more generally based on prior feedback. There are a few
comments regarding how certain interfaces are used by ThinLTO, and the
options added here to gold currently have ThinLTO-specific names as the
behavior they provoke is currently ThinLTO-specific.

This patch includes support for generating per-module function indexes,
the combined index file via the gold plugin, and several tests
(more are included with the associated clang patch D11908).

Reviewers: dexonsmith, davidxl, joker.eph

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D13107

llvm-svn: 249270

When the ScopAnnotator was a class member variable some of the maps it contains
have not been properly cleared. As a result we had dangling pointers to
llvm::Value(s) which got detected by the AssertingVH we recently added.

No test case as this issue is hard to reproduce reliably as subsequent
optimizations need to delete some of the llvm::Values we still keep in our
lists.

llvm-svn: 249269

llvm-svn: 249268

By using AssertingVH we will see assertions in case Values to which still
pointers in our maps exists are deleted. This is very useful as we previously
had some bugs that were caused by such stale Value pointers.

llvm-svn: 249267

The use of const qualified Value pointers prevents the use of AssertingVH. We
could probably think of adding const support to AssertingVH, but as const
correctness seems to currently provide limited benefit in Polly, we do not do
this yet.

llvm-svn: 249266

llvm-svn: 249265

There have been various places where llvm::DenseMap<const llvm::Value *,
llvm::Value *> types have been defined, but all types have been expected to be
identical. We make this more clear by consolidating the different types and use
BlockGenerator::ValueMapT wherever there is a need for types to match
BlockGenerator::ValueMapT.

llvm-svn: 249264

llvm-svn: 249263

llvm-svn: 249262

Added tests for intrinsics and encoding.

Differential Revision: http://reviews.llvm.org/D12690

llvm-svn: 249261

llvm-svn: 249260

llvm-svn: 249259

llvm-svn: 249258

Track which basic blocks belong to which funclets.  Permit branch
folding to fire but only if it can prove that doing so will not cause
code in one funclet to be reused in another.

llvm-svn: 249257

When the readline target exists (only for non-Android Linux currently),
ensure that target is made a dependency of the finish_swig python-wrap-up
steps.  This ensures it is built when building the lldb target.

Fixes:
https://llvm.org/bugs/show_bug.cgi?id=25038

llvm-svn: 249256

Add tests to ensure we handle this case this case gracefully.

llvm-svn: 249255

I saw these in the wild while trying to link shared libraries.

llvm-svn: 249254

llvm-svn: 249253

Diagnose when a pointer to const T is used as the first argument in at atomic
builtin unless that builtin is a load operation. This is already checked for
C11 atomics builtins but not for __atomic ones.

This patch was given the LGTM by rsmith when it was part
of a larger review. (See http://reviews.llvm.org/D10407)

llvm-svn: 249252

Updated the FADD combines to work with vectors as well as scalars.

Differential Revision: http://reviews.llvm.org/D13416

llvm-svn: 249251

These are based on PR25016 and likely caused by a bug in
MachineCombiner's definition of improvesCriticalPathLen().

llvm-svn: 249249

llvm-svn: 249248

llvm-svn: 249247