Summary: Now that we prioritize copying trivial types over using const-references where possible, I found some cases where, after the transformation, the loop was using the address of the local copy instead of the original object.

Reviewers: klimek

Subscribers: alexfh, cfe-commits

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

llvm-svn: 249300

Reviewers: jaydeep.
Subscribers: lldb-commits.
Differential Revision: http://reviews.llvm.org/D13335

llvm-svn: 249299

There are two remaining buildbot failures that we'll have to
investigate before submitting this again.

llvm-svn: 249298

The entries are added if there are "_init" or "_fini" entries in
the symbol table respectively. According to the behavior of ld,
entries are inserted even for undefined symbols.

Symbol names can be overridden by using -init and -fini command
line switches. If used, these switches neither add new symbol table
entries nor require those symbols to be resolved.

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

llvm-svn: 249297

Try to make the Windows buildbots happy by fixing the regexes that match the
paths to CRT files.

llvm-svn: 249296

Add symbol specified with -u as undefined which may cause additional
object files from archives to be linked into the resulting binary.

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

llvm-svn: 249295

r249137 added support for the new mips-mti-linux toolchain. However,
the new tests of that commit, broke some buildbots because they didn't use
the correct regular expressions to capture the filename of Clang & LLD.

This commit re-applies the changes of r249137 and fixes the tests in
r249137 in order to match the filenames of the Clang and LLD executable.

llvm-svn: 249294

Summary:
https://llvm.org/bugs/show_bug.cgi?id=24960

modernize-use-nullptr would hit an assertion in some cases involving macros and initializer lists, due to finding a node with more than one parent (the two forms of the initializer list).

However, this doesn't mean that the replacement is incorrect, so instead of just rejecting this case I tried to find a way to make it work. Looking at the semantic form of the InitListExpr made sense to me (looking at both forms results in false negatives) but I am not sure of the things that we can miss by skipping the syntactic form.

Reviewers: klimek

Subscribers: cfe-commits, alexfh

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

llvm-svn: 249291

statement. Specifically, we don't want people that have already written
a patch to just write a style guide for their 1-person project.

llvm-svn: 249290

llvm-svn: 249289

llvm-svn: 249288

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