We don't want to filter out the builtins that are present in libSystem like we do for the normal builtins because kexts can't link libSystem, but we should filter out all the builtins that are generally not supported on the OS and architecture.

llvm-svn: 248756

set help messages.
<rdar://problem/22870082> 

llvm-svn: 248755

llvm-svn: 248754

Currently it's 64-bit which will lead to mismatch between host and
device code if we compile for i386.

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

llvm-svn: 248753

[CMake] Accidentally committed code that was using a variable only populated in some earlier code. NFC.

llvm-svn: 248752

For Darwin simulator platforms we shouldn't build the cc_kext builtins at all because they aren't applicable, and we should includ the simulator builtins as slices inside the main platform builtin library.

llvm-svn: 248751

llvm-svn: 248750

llvm-svn: 248749

llvm-svn: 248747

llvm-svn: 248746

llvm-svn: 248745

[CMake] [Darwin] [builtins] Exclude aeabi builtins from iOS arm32 architectures since we don't support aeabi on iOS.

llvm-svn: 248744

`ScalarEvolution::isImpliedCondOperandsViaNoOverflow` tries to cast the
operand type of the comparison it is given to an `IntegerType`.  This is
incorrect because it could actually be simplifying a comparison between
two pointers.  Switch it to using `getTypeSizeInBits` instead, which
does the right thing for both pointers and integers.

Fixed PR24956.

llvm-svn: 248743

llvm-svn: 248742

When used recursively, this would set the kill flag
on the intermediate step from first splitting
x16 to x8.

llvm-svn: 248741

llvm-svn: 248740

The splitting of > 4 dword SMRD instructions
if using an offset in an SGPR instead of an immediate
was not setting the destination register,
resulting an an instruction missing an operand
which would assert later.

Test will be included in a following commit
which fixes a related issue.

llvm-svn: 248739

Make sure we are testing moving users
of the moved and split SMRD loads.

llvm-svn: 248738

Run instnamer on it, and rename check prefix.

This is in preparation for adding new testcases to cover
bugs on other subtargets.

llvm-svn: 248737

llvm-svn: 248736

Patch by Slava Klochkov (vyacheslav.n.klochkov@intel.com)

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

llvm-svn: 248735

Temporary fix till InstCombine and other possible passes will be
efficient to handle multiple assumes.

llvm-svn: 248734

Patch by George Rimar!

llvm-svn: 248733

This is a basic initial implementation of the -flat_namespace and
-undefined options for LLD-darwin. It ignores several subtlties,
but the result is close enough that we can now link LLVM (but not
clang) on Darwin and pass all regression tests.

llvm-svn: 248732

llvm-svn: 248731

llvm-svn: 248730

llvm-svn: 248729

Patch by Jake VanAdrighem!

Summary:
Fix the way we sort the llvm.used and llvm.compiler.used members.

This bug seems to have been introduced in rL183756 through a set of improper casts to GlobalValue*. In subsequent patches this problem was missed and transformed into a getName call on a ConstantExpr.

Reviewers: silvas

Subscribers: silvas, llvm-commits

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

llvm-svn: 248728

1. Use a worklist, not a recursive approach, to avoid needless
   revisitation and being repeatedly forced to jump back to the
   start of the BB if a handle is invalidated.

2. Only insert operands to the worklist if they become unused
   after a dead instruction is removed, so we don’t have to
   visit them again in most cases.

3. Use a SmallSetVector to track the worklist.

4. Instead of pre-initting the SmallSetVector like in
   DeadCodeEliminationPass, only put things into the worklist
   if they have to be revisited after the first run-through.
   This minimizes how much the actual SmallSetVector gets used,
   which saves a lot of time.

llvm-svn: 248727

llvm-svn: 248726

Summary:
The P5600 is an out-of-order, superscalar implementation of the MIPS32R5
architecture.

The scheduler has a few missing details (see the 'Tricky Instructions'
section and some quirks of the P5600 are deliberately omitted due to
implementation difficulty and low chance of significant benefit (e.g. the
predicate on P5600WriteEitherALU). However, testing on SingleSource is
showing significant performance benefits on some apps (seven in the 10-30%
range) and only one significant regression (12%) when
-pre-RA-sched=linearize is given. Without -pre-RA-sched=linearize the
results are more variable. Some do even better (up to 55% improvement) but
increased numbers of copies are slowing others down (up to 12%).

Overall, the scheduler as it currently stands is a 2.4% win with
-pre-RA-sched=linearize and a 2.7% win without -pre-RA-sched=linearize.
I'm sure we can improve on this further.

For completeness, the FPGA this was tested on shows some failures with and
without the P5600 scheduler. These appear to be scheduling related since
the two test runs have fairly different sets of failing tests even after
accounting for other factors (e.g. spurious connection failures) however
it's not P5600 specific since we also get some for the generic scheduler.

Reviewers: vkalintiris

Subscribers: mpf, llvm-commits, atrick, vkalintiris

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

llvm-svn: 248725

llvm-svn: 248724

Summary:
compile_commands.json is usually generated in the build directory.
Projects like LLVM/Clang enforce out-of-source builds.
This option allow allow such projects to work out of the box, without
moving the compilation database manually.

The naming of the option is similar to the one use by other tools:

    clang-{check,modernize,query,rename,tidy} -p=<build_path> <...>

Reviewers: alexfh

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

llvm-svn: 248723

llvm-svn: 248722

Reviewed By: hfinkel

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

llvm-svn: 248721

llvm-svn: 248720

This was split off of http://reviews.llvm.org/D13040 to make it easier to test the correctness of the implication logic. For the moment, this only handles a single easy case which shows up when eliminating and combining range checks. In the (near) future, I plan to extend this for other cases which show up in range checks, but I wanted to make those changes incrementally once the framework was in place.

At the moment, the implication logic will be used by three places. One in InstSimplify (this review) and two in SimplifyCFG (http://reviews.llvm.org/D13040 & http://reviews.llvm.org/D13070). Can anyone think of other locations this style of reasoning would make sense?

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

llvm-svn: 248719

Originally, debug intrinsics and annotation intrinsics may prevent
the loop to be rerolled, now they are ignored.

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

llvm-svn: 248718

While debugging, this makes it easier to understand due to which memory
reference these stores have been introduced.

llvm-svn: 248717

llvm-svn: 248716