llvm-svn: 178083

llvm-svn: 178082

llvm-svn: 178081

All Intel CPUs since Yonah look a lot alike, at least at the granularity
of the scheduling models. We can add more accurate models for
processors that aren't Sandy Bridge if required. Haswell will probably
need its own.

The Atom processor and anything based on NetBurst is completely
different. So are the non-Intel chips.

llvm-svn: 178080

llvm-svn: 178079

This will be used to factor out some uses of magic number operand offsets
inside Clang where these fields were updated in an effort to resolve forward
declarations/circular references.

llvm-svn: 178078

As suggested by Bill Schmidt (in reviewing r178067), use the real register
number bit lengths (which is self-documenting, and prevents using illegal
numbers), and set only the relevant bits in HWEncoding (which defaults to 0).

No functionality change intended.

llvm-svn: 178077

The algorithm to access an item in a __NSArrayM was not reacting properly to deletions
The fix is to use a smarter formula that accounts for items shifting and the resulting notion of offsets in the table

llvm-svn: 178076

Tighten up the iterator requirements for the vector member templates.  This is especially important for the constructors so that is_constructible<vector<T>, I, I> gives the right answer when T can not be constructed from *I.  Test case included for this latter point.

llvm-svn: 178075

Allow variants to be defined only for some processors on a target.

llvm-svn: 178074

As pointed out by Richard Sandiford, my recent updates to the register
scavenger broke targets that use custom spilling (because the new code assumed
that if there were no valid spill slots, than spilling would be impossible).

I don't have a test case, but it should be possible to create one for Thumb 1,
Mips 16, etc.

llvm-svn: 178073

Make format uint64_t[] actually work as designed

llvm-svn: 178072

llvm-svn: 178071

llvm-svn: 178070

llvm-svn: 178069

llvm-svn: 178068

As pointed out by Jakob, we don't need to maintain a separate
register-numbering table. Instead we should let TableGen generate the table for
us from the information (already present) in PPCRegisterInfo.td.
TRI->getEncodingValue is now used to access register-encoding values.

No functionality change intended.

llvm-svn: 178067

llvm-svn: 178065

Another vector debug mode test, and a static test on Allocator::value_type.  This partially addresses http://llvm.org/bugs/show_bug.cgi?id=15576.

llvm-svn: 178064

[analyzer] Change inlining policy to inline small functions when reanalyzing ObjC methods as top level.

This allows us to better reason about(inline) small wrapper functions.

llvm-svn: 178063

llvm-svn: 178062

With dosish filename, it misgenerates an improper extra entry.

!1 = metadata !{metadata !"E:\5Cllvm\5Cllvm-project\5Cclang\5Ctest\5CCodeGenCXX/debug-info-namespace.cpp", metadata !"E:\5Cllvm\5Cbuild\5Cninja-win32-vs11\5Ctools\5Cclang\5Ctest\5CCodeGenCXX"}

!8 = metadata !{metadata !"E:\5Cllvm\5Cllvm-project\5Cclang\5Ctest\5CCodeGenCXX\5Cdebug-info-namespace.cpp", metadata !"E:\5Cllvm\5Cbuild\5Cninja-win32-vs11\5Ctools\5Cclang\5Ctest\5CCodeGenCXX"}

!8 is unexpected.

llvm-svn: 178061

Now that the register scavenger can support multiple spill slots, and PEI can
use virtual-register-based scavenging for multiple simultaneous registers, we
can use a virtual register for the transfer register in the CR spilling code.

This should eliminate the last place (outside of the prologue/epilogue) where
we depend on the unconditional availability of the r0 register. We will soon be
able to allocate it (in a somewhat restricted sense) as a GPR.

llvm-svn: 178060

PPC's use of PEI's virtual-register-based scavenging functionality had
redefined the virtual registers (it was non-SSA). Now that PEI supports
dealing with instructions with multiple virtual registers, this can be
cleanup up to use multiple virtual registers and keep SSA form.

No functionality change intended.

llvm-svn: 178059

The previous algorithm could not deal properly with scavenging multiple virtual
registers because it kept only one live virtual -> physical mapping (and
iterated through operands in order). Now we don't maintain a current mapping,
but rather use replaceRegWith to completely remove the virtual register as
soon as the mapping is established.

In order to allow the register scavenger to return a physical register killed
by an instruction for definition by that same instruction, we now call
RS->forward(I) prior to eliminating virtual registers defined in I. This
requires a minor update to forward to ignore virtual registers.

These new features will be tested in forthcoming commits.

llvm-svn: 178058

- Making an error message more consistent
- Ensuring the element size is not zero before using it in a modulus
- Properly using target settings to cap the std::list element count
- Removing spurious element size calculations that were unused
- Removing spurious capping in std::map

llvm-svn: 178057

llvm-svn: 178056

It is unused since pic support went away.

llvm-svn: 178055

Required making a handful of changes to the table generator.  Also adds
an unspecified inheritance attribute.  This opens the path for us to
apply these attributes to C++ records implicitly.

llvm-svn: 178054

Initialize CalleeWithThisReturn to 0 in the constructor.
Also revert r170815 since checking CalleeWithThisReturn is faster.

PR15598

llvm-svn: 178053

That wasn't a typo, if the short letter option is from a non-obvious source, I capitolize it in the help as an aid to memory.

llvm-svn: 178052

Now all x86 instructions that have itinerary classes also have SchedRW
lists. This is required before the new scheduling models can be used.

There are still unannotated instructions remaining, but they don't have
itinerary classes either.

llvm-svn: 178051

This only covers the instructions that were given itinerary classes for
the Atom model.

llvm-svn: 178050

This could definitely be more granular. I am not sure if it makes a
difference.

llvm-svn: 178049

llvm-svn: 178048

llvm-svn: 178047

- 'prefetch' intrinsics are only lowered when SSE is available. On non-X86
  builds, 'generic' CPU is used and stops lowering any prefetch intrinsics.

llvm-svn: 178046

This is a compile time optimization. Before the patch we would do two traversals
on each call to aliasGEP - one with a set size parameter one with UnknownSize.
We can do better by first checking the result of the alias query with
UnknownSize.
Only if this one returns MayAlias do we query a second time using size and type.

This recovers an about 7% compile time regression on spec/ammp.

radar://12349960

llvm-svn: 178045

Our commands that end up displaying a ValueObject as part of their workflow use OptionGroupValueObjectDisplay as their currency for deciding the final representation
ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose

The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code
This checkin provides one and only one (and hopefully correct :-) entry point for this conversion

llvm-svn: 178044

llvm-svn: 178043