If anybody is actually using this, it probably doesn't do what they
think it does. This actually causes the dylib to *export* a
__cxa_atexit symbol, so anything that links it probably loses their
exit time destructors as well as disabling LLVM's.

This just removes the option entirely. If somebody does need this
behaviour we should figure out a more principled way to do it.

This is effectively a revert of r223805.

llvm-svn: 263498

Summary:
llvm-config --libs does not produce correct output since commit r260263
(llvm-config: Add preliminary Windows support) changed naming format of
the libraries. This patch updates llvm-config to recognize new naming
format and output correct linker flags.

Ref: https://llvm.org/bugs/show_bug.cgi?id=26581

Patch by Vedran Miletić

Reviewers: ehsan, rnk, pxli168

Subscribers: pxli168

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

llvm-svn: 263497

llvm-svn: 263496

Summary: There are places in MachineBlockPlacement where a worklist is filled in pretty much identical way. The code is duplicated. This refactor it so that the same code is used in both scenarii.

Reviewers: chandlerc, majnemer, rafael, MatzeB, escha, silvas

Subscribers: llvm-commits

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

llvm-svn: 263495

This reverts commit r263491. Missed a file on the LLVM side.

llvm-svn: 263494

This reverts commit r263490. Missed a file.

llvm-svn: 263493

This is the companion to an LLVM patch that renamed the function index
data structures and files to use the more general module summary index.

llvm-svn: 263491

With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (started in
r263275) to reflect the wider scope. In particular, changed the
FunctionIndex* data structures to ModuleIndex*, and renamed related
variables and comments. Also renamed the files to reflect the changes.

A companion clang patch will immediately succeed this patch to reflect
this renaming.

llvm-svn: 263490

Summary:
This check was added in rL152620, and has started causing downstream warnings in Julia:
```
In file included from /home/tkelman/Julia/julia-0.5/src/codegen.cpp:22:0:
/home/tkelman/Julia/julia-0.5/usr/include/llvm/ExecutionEngine/JITEventListener.h:84:5: warning: "LLVM_USE_INTEL_JITEVENTS" is not defined [-Wundef]
 #if LLVM_USE_INTEL_JITEVENTS
     ^
/home/tkelman/Julia/julia-0.5/usr/include/llvm/ExecutionEngine/JITEventListener.h:100:5: warning: "LLVM_USE_OPROFILE" is not defined [-Wundef]
 #if LLVM_USE_OPROFILE
     ^
```

Patch by Tony Kelman.
Reviewers: loladiro
Differential Revision: http://reviews.llvm.org/D17254

llvm-svn: 263487

On FreeBSD _LIBCPP_EXTERN_TEMPLATE is being defined from something
included by lldb/lldb-private.h. Undefine it after the #include to avoid
the redefinition warning.

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

llvm-svn: 263486

This reverts commit r263472.

There is an LNT failure on clang-ppc64be-linux-lnt.  Turn this off,
while I am investigating.

llvm-svn: 263485

This is a big update that gets the public configurations more in line with the ones we're actually using internally to ship Clang in Xcode.

From here forward I expect most of the changes in these files to be incremental as the changes get made internally.

llvm-svn: 263483

As noted in:
https://llvm.org/bugs/show_bug.cgi?id=26636

This doesn't accomplish anything on its own. It's the first step towards preserving 
and using branch weights with selects.

The next step would be to make sure we're propagating the info in all of the other
places where we create selects (SimplifyCFG, InstCombine, etc). I don't think there's
an easy fix to make this happen; we have to look at each transform individually to 
determine how to correctly propagate the weights.

Along with that step, we need to then use the weights when making subsequent transform
decisions such as discussed in http://reviews.llvm.org/D16836.

The inliner test is independent but closely related. It verifies that metadata is
preserved when both branches and selects are cloned.

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

llvm-svn: 263482

Summary:
Previously we had a notion of convergent functions but not of convergent
calls.  This is insufficient to correctly analyze calls where the target
is unknown, e.g. indirect calls.

Now a call is convergent if it targets a known-convergent function, or
if it's explicitly marked as convergent.  As usual, we can remove
convergent where we can prove that no convergent operations are
performed in the call.

Originally landed as r261544, then reverted in r261544 for (incidental)
build breakage.  Re-landed here with no changes.

Reviewers: chandlerc, jingyue

Subscribers: llvm-commits, tra, jhen, hfinkel

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

llvm-svn: 263481

llvm-svn: 263480

llvm-svn: 263479

Some instructions were missing isBranch, isCall, or isTerminator
flags.  This didn't really affect code generation since most of
the affected patterns were used only for the AsmParser and/or
disassembler.

However, it could affect tools using the MC layer to disassemble
and parse binary code (e.g. via MCInstrDesc::mayAffectControlFlow).

llvm-svn: 263478

Should fix ARM bots.

llvm-svn: 263477

Summary:
DemandedBits was added to the requirements of SLPVectorizer in rL261212
(and various earlier version of it), but the appropriate initialization
statement was accidentally forgotten.

Ref [[ https://github.com/JuliaLang/julia/issues/14998 | JuliaLang/julia#14998 ]].

Patch by Yichao Yu.
Reviewers: mssimpso
Differential Revision: http://reviews.llvm.org/D18152

llvm-svn: 263476

Reverting r263474; it turns out there are uses of the public interface, but MSVC wasn't caring about them.

http://lab.llvm.org:8080/green//job/clang-stage1-cmake-RA-incremental_build/21475/consoleFull#-45876453249ba4694-19c4-4d7e-bec5-911270d8a58c
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/8879

llvm-svn: 263475

The file header of TrailingObjects.h suggests that TrailingObjects be inherited privately because the public APIs it exposes are not meant as part of the interface. There's no functional change because nothing currently relied on these being inherited publicly.

llvm-svn: 263474

llvm-svn: 263473

The two issues that were discovered got fixed (r263058, r263173).

The pass can be disabled with -mllvm -enable-loop-load-elim=0

llvm-svn: 263472

This reverts commit r263366 because it caused link errors in some linkers.

llvm-svn: 263471

Automatic Semicolon Insertion can only be properly handled by parsing
source code. However conservatively catching just a few, common
situations prevents breaking code during development, which greatly
improves usability.

JS code should still use semicolons, and ASI code should be flagged by
a compiler or linter.

Patch by Martin Probst. Thank you.

llvm-svn: 263470

The relative vtable ABI will use a struct rather than an array as the type
of a vtable. LLVM only allows 32-bit integers as struct indices, so we need
to use 32-bit integers to get addresses of address points. In order to keep
the code simple, we might as well do that unconditionally.

It's probably a reasonable implementation limit to support no more than 2
billion virtual functions per class.

This change causes quite a bit of churn in the test suite, so I'm making
it separately.

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

llvm-svn: 263469

llvm-svn: 263468

In r262970 this was changed from xfail Clang < 3.5 to > 3.5, but it
still fails on FreeBSD 10's system Clang 3.4.1 so assume it fails on
all versions.

llvm.org/pr26937

llvm-svn: 263467

llvm-svn: 263466

This marks virtual function declarations, as well as runtime library functions
__cxa_pure_virtual, __cxa_deleted_virtual and _purecall, as unnamed_addr. This
will allow us to correctly form relative references to them from vtables in
the relative vtable ABI.

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

llvm-svn: 263464

This fixes PR26843.

llvm-svn: 263462

http://reviews.llvm.org/D18125
Patch by Aditya Kumar.

llvm-svn: 263461

The bad behavior happens when we have a function with a long linear chain of
basic blocks, and have a live range spanning most of this chain, but with very
few uses.
Let say we have only 2 uses.
The Hopfield network is only seeded with two active blocks where the uses are,
and each iteration of the outer loop in `RAGreedy::growRegion()` only adds two
new nodes to the network due to the completely linear shape of the CFG.
Meanwhile, `SpillPlacer->iterate()` visits the whole set of discovered nodes,
which adds up to a quadratic algorithm.

This is an historical accident effect from r129188.

When the Hopfield network is expanding, most of the action is happening on the
frontier where new nodes are being added. The internal nodes in the network are
not likely to be flip-flopping much, or they will at least settle down very
quickly. This means that while `SpillPlacer->iterate()` is recomputing all the
nodes in the network, it is probably only the two frontier nodes that are
changing their output.

Instead of recomputing the whole network on each iteration, we can maintain a
SparseSet of nodes that need to be updated:

- `SpillPlacement::activate()` adds the node to the todo list.
- When a node changes value (i.e., `update()` returns true), its neighbors are
  added to the todo list.
- `SpillPlacement::iterate()` only updates the nodes in the list.

The result of Hopfield iterations is not necessarily exact. It should converge
to a local minimum, but there is no guarantee that it will find a global
minimum. It is possible that updating nodes in a different order will cause us
to switch to a different local minimum. In other words, this is not NFC, but
although I saw a few runtime improvements and regressions when I benchmarked
this change, those were side effects and actually the performance change is in
the noise as expected.

Huge thanks to Jakob Stoklund Olesen <stoklund@2pi.dk> for his feedbacks,
guidance and time for the review.

llvm-svn: 263460

When the SP in not changed because of realignment/VLAs etc., we restore the SP
by using the previous value of SP and not the FP. Breaking the dependency will
help in cases when the epilog of a callee is close to the epilog of the caller;
for then "sub sp, fp, #" depends on the load restoring the FP in the epilog of
the callee.

http://reviews.llvm.org/D18060
Patch by Aditya Kumar and Evandro Menezes.

llvm-svn: 263458

The next commit will use it.

llvm-svn: 263455

llvm-svn: 263454

llvm-svn: 263453

llvm-svn: 263451

llvm-svn: 263450

implementation units of modules rather than interface units.

llvm-svn: 263449