llvm-svn: 230570

llvm-svn: 230569

This lets us compile programs which make use of exceptional constructs
statically without executing any of them dynamically.

llvm-svn: 230568

This particular subtype of Mach-O was missing. Add it.

llvm-svn: 230567

This symbol exists only to pull in the required pieces of the runtime,
so nothing ever needs to refer to it. Making it hidden avoids the
potential for issues with duplicate symbols when linking profiled
libraries together.

llvm-svn: 230566

Remove a newline from `AssemblyWriter::printMDNodeBody()`, and add one
to `AssemblyWriter::writeMDNode()`.  NFCI for assembly output.

However, this drops an inconsistent newline from `Metadata::print()`
when `this` is an `MDNode`.  Now the newline added by `Metadata::dump()`
won't look so verbose.

llvm-svn: 230565

This is a follow-on to r227491 which tightens the check for propagating FP
values. If a non-constant value happens to be a zero, we would hit the same
bug as before.

Bug noted and patch suggested by Eli Friedman.

llvm-svn: 230564

Remove a default argument that's never passed and a constructor that's
never called.

llvm-svn: 230563

Optimize finding the Complete Definition of an ObjC class for debug with .o files with lots of .o files.
 
When we have a debug map we have an executable with a bunch of STAB symbols and each source file has a N_SO symbol which scopes a bunch of symbols inside of it. We can use this to our advantage here when looking for the complete definition of an objective C class by looking for a symbol whose name matches the class name and whose type is eSymbolTypeObjCClass. If we find one, that symbol will be contained within a N_SO symbol. This symbol gets turned into a symbol whose type is eSymbolTypeSourceFile and that symbol will contain the eSymbolTypeObjCClass which helps us to locate the correct .o file and allows us to only look in that file.

To further accelerate things, if we are looking for the implementation, we can avoid looking at all .o files if we don't find a matching symbol because we have a debug map, which means the objective C symbol for the class can't have been stripped, so we can safely not search all remaining .o files. This will save us lots of time when trying to look for "NSObject" and any other AppKit and Foundation classes that we never have implementation definitions for.

<rdar://problem/19234225>

llvm-svn: 230562

the .h file. It's used in only one place (other than recursively)
and there's no need to include it everywhere.

Saves almost 900k from total llvm object file size.

llvm-svn: 230561

Summary: SROA generates code that isn't quite as easy to optimize and contains unusual-sized shuffles, but that code is generally correct. As discussed in D7487 the right place to clean things up is InstCombine, which will pick up the type-punning pattern and transform it into a more obvious bitcast+extractelement, while leaving the other patterns SROA encounters as-is.

Test Plan: make check

Reviewers: jvoung, chandlerc

Subscribers: llvm-commits
llvm-svn: 230560

llvm-svn: 230559

one can give us more lookup results (due to implicit special members). Be sure
to complete the redecl chain for every kind of DeclContext before performing a
lookup into it, rather than only doing so for NamespaceDecls.

llvm-svn: 230558

Summary: Newlib supports ctype differently from other platforms, this patch teaches libc++ about yet another platform that does ctype differently.

Reviewers: jroelofs

Subscribers: cfe-commits, danalbert, EricWF, jvoung, jfb, mclow.lists

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

llvm-svn: 230557

Add qModuleInfo request in order to get module information (uuid, triple,..) by module path from remote platform.

http://reviews.llvm.org/D7709

llvm-svn: 230556

It turns out we have a macro to ensure that debuggers can access
`dump()` methods.  Use it.  Hopefully this will prevent me (and others)
from committing crimes like in r223802 (search for /10000/, or just see
the fix in r224407).

llvm-svn: 230555

It seems ArrayRefs to multi-dimensional arrays confuse some compilers.

llvm-svn: 230554

LDtocL, and other loads that roughly correspond to the TOC_ENTRY SDAG node,
represent loads from the TOC, which is invariant. As a result, these loads can
be hoisted out of loops, etc. In order to do this, we need to generate
GOT-style MMOs for TOC_ENTRY, which requires treating it as a legitimate memory
intrinsic node type. Once this is done, the MMO transfer is automatically
handled for TableGen-driven instruction selection, and for nodes generated
directly in PPCISelDAGToDAG, we need to transfer the MMOs manually.

Also, we were not transferring MMOs associated with pre-increment loads, so do
that too.

Lastly, this fixes an exposed bug where R30 was not added as a defined operand of
UpdateGBR.

This problem was highlighted by an example (used to generate the test case)
posted to llvmdev by Francois Pichet.

llvm-svn: 230553

  It is important we add more publications with/about Polly so people
  can see that work and research is actually ongoing.

llvm-svn: 230552

This adds support for pretty-printing instruction operands. The new
output looks like:

00000000 00000010 ffffffff CIE
  Version:               1
  Augmentation:
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8

  DW_CFA_def_cfa:  reg4 +4
  DW_CFA_offset:  reg8 -4
  DW_CFA_nop:
  DW_CFA_nop:

00000014 00000010 00000000 FDE cie=00000000 pc=00000000...00000022
  DW_CFA_advance_loc:  3
  DW_CFA_def_cfa_offset:  +12
  DW_CFA_nop:

llvm-svn: 230551

CIE pointers were never filled in before, and printing the pointer
is totally pointless anyway.

llvm-svn: 230550

Move the FrameEntry::dumpInstructions down in the file at some
place where it can see the declarations of FDE and CIE.

llvm-svn: 230549

To be used for dumping.

llvm-svn: 230548

This is the first commit in a small series aiming at making
debug_frame dump more useful (right now it prints a list of
opeartions without their operands).

llvm-svn: 230547

llvm-svn: 230546

llvm-svn: 230545

r230290 released the LLVM module but not the LTOModule.

rdar://19024554

llvm-svn: 230544

The Win64 epilogue structure is very restrictive, it permits a very
small number of opcodes and none of them are 'mov'.

This means that given:
  mov %rbp, %rsp
  pop %rbp

The mov isn't the epilogue, only the pop is.  This is problematic unless
a frame pointer is present in which case we are free to do whatever we'd
like in the "body" of the function.  If a frame pointer is present,
unwinding will undo the prologue operations in reverse order regardless
of the fact that we are at an instruction which is reseting the stack
pointer.

llvm-svn: 230543

between them.

llvm-svn: 230542

llvm-svn: 230541

This change aligns globals to the next highest power of 2 bytes, up to a
maximum of 128. This makes it more likely that we will be able to compress
bit sets with a greater alignment. In many more cases, we can now take
advantage of a new optimization also introduced in this patch that removes
bit set checks if the bit set is all ones.

The 128 byte maximum was found to provide the best tradeoff between instruction
overhead and data overhead in a recent build of Chromium. It allows us to
remove ~2.4MB of instructions at the cost of ~250KB of data.

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

llvm-svn: 230540

This allows clang-cl to self-host cleanly with no magic setup
steps required.

After this patch, all you have to do is set CC=CXX=clang-cl and
run cmake -G Ninja.

These changes only exist to support C++ features which are
unsupported in clang-cl, so regardless of whether the user
specifies they want to use them, we still have to disable them.

llvm-svn: 230539

llvm-svn: 230538

llvm-svn: 230537

This rule works like check-cfi, but fails if the tests are unsupported.
This is useful to run on bots if we want to be sure that the tests aren't
silently being skipped.

llvm-svn: 230536

llvm-svn: 230535

Previously we allowed these casts only for constants declared in system
headers, which we assume are retain/release-neutral. Now also allow them
for constants in user headers, treating them as +0.  Practically, this
means that we will now allow:
id x = (id)kMyGlobalConst;

But unlike with system headers we cannot mix them with +1 values:
id y = (id)(b ? kMyGlobalConst : [Obj newValAtPlusOne]); // error
id z = (id)(b ? kSystemGlobalConst: [Obj newValAtPlusOne]); // OK

Thanks to John for suggesting this improvement.

llvm-svn: 230534

    
(The change was landed in r230280 and caused the regression PR22674.
This version contains a fix and a test-case for PR22674).
    
When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.
    
This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.
    
Apart from the attached test case, another (more realistic)
manifestation of the bug can be seen in
Transforms/IndVarSimplify/pr20680.ll.

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

llvm-svn: 230533

llvm-svn: 230532

SWIG doesn't like enum : unsigned.  Revert this until I can
fix this in a way that swig likes.

llvm-svn: 230531