llvm-svn: 248768

There are always more physical registers and register units so the
previous behaviour was correct but we can do with less memory.

llvm-svn: 248767

Remove unnecessary default dtor. The base dtor is already virtual and the derived dtor adds nothing.

llvm-svn: 248765

This is a bit of an awkward API and I'm not sure what the right solution
is. Having a publicly copy constructible base class makes it easy to
accidentally slice derived objects in a number of contexts.

llvm-svn: 248764

Previously we were hijacking the old LandingPadInfo data structures to
communicate our state numbers. Now we don't need that anymore.

llvm-svn: 248763

Thanks to echristo for noticing!

llvm-svn: 248762

LookupResult should not be copyable, it's not readily copyable and can
only be copied when it's in specific states (in a query state, without
any results, basically). Instead, just extract the /query/ state and
pass that across the copy boundary, then build a new LookupResult on the
other side.

I wonder if a better API (one in which the query state is separate from
the result state - essentialyl making QueryState a first class part of
the Lookup API - pass a QueryState, get a LookupResult, rather than
mutating the LookupResult in place (LookupResult could contain a
QueryState if it's particularly helpful to be able to observe the query
parameters while also examining the result)) might be a good idea here.

Future patches will probably make LookupResult actually non-copyable
(transition the CXXBasePaths to unique_ptr, for example) and hopefully
we'll enable -Wdeprecated in LLVM soon to avoid issues like this.

llvm-svn: 248761

Add an explicitly defaulted copy ctor (and FIXME) to Command since its copy ctor is currently used (and actually slices derived objects... ) in some diagnostics handling.

Justin mentioned he'd look into this.

llvm-svn: 248760

And also remove an unused variable that's now diagnosed by
-Wunused-variable since the dtor is now trivial.

llvm-svn: 248759

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