The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.

llvm-svn: 169312

This reapplies the fix for PR13303 now with more justification. Based on my
execution of the GDB 7.5 test suite this results in:

expected passes: 16101 -> 20890 (+30%)
unexpected failures: 4826 -> 637 (-77%)

There are 23 checks that used to pass and now fail. They are all in
gdb.reverse. Investigating a few looks like they were accidentally passing
due to extra breakpoints being set by this bug. They're generally due to the
difference in end location between gcc and clang, the test suite is trying to
set breakpoints on the closing '}' that clang doesn't associate with any
instructions.

llvm-svn: 169304

missed in the first pass because the script didn't yet handle include
guards.

Note that the script is now able to handle all of these headers without
manual edits. =]

llvm-svn: 169224

The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.

llvm-svn: 169218

llvm-svn: 169198

the alignment is clamped to TargetFrameLowering.getStackAlignment if the target
does not support stack realignment or the option "realign-stack" is off.

This will cause miscompile if the address is treated as aligned and add is
replaced with or in DAGCombine.

Added a bool StackRealignable to TargetFrameLowering to check whether stack
realignment is implemented for the target. Also added a bool RealignOption
to MachineFrameInfo to check whether the option "realign-stack" is on.

rdar://12713765

llvm-svn: 169197

llvm-svn: 169196

Now that there can be multiple hint registers from targets, it doesn't
make sense to have a function that returns 'the' preferred register.

llvm-svn: 169190

Targets can provide multiple hints now, so getRegAllocPref() doesn't
make sense any longer because it only returns one preferred register.
Replace it with getSimpleHint() in the remaining heuristics. This
function only

llvm-svn: 169188

No functional change for this commit. The follow-up patch will add more stuff to
these functions.

rdar://12713765

llvm-svn: 169186

Virtual registers with a known preferred register are prioritized by
RAGreedy. This function makes the condition explicit without depending
on getRegAllocPref().

llvm-svn: 169179

This simplifies the hinting code quite a bit while making the targets
easier to write at the same time.

llvm-svn: 169173

moves doInitialization and doFinalization to the Pass class and removes some unreachable code in MachineModuleInfo

reviewed by Evan Cheng <evan.cheng@apple.com>

llvm-svn: 169164

The TargetRegisterInfo::getRegAllocationHints() function is going to
replace the existing mechanisms for providing target-dependent hints to
the register allocator: ResolveRegAllocHint() and
getRawAllocationOrder().

The new hook is more flexible because it allows the target to provide
multiple preferred candidate registers for each virtual register, and it
is easier to use because targets are not required to return a reference
to a constant array like getRawAllocationOrder().

An optional VirtRegMap argument can be used to provide target-dependent
hints that depend on the provisional assignments of other virtual
registers.

llvm-svn: 169154

Thanks Eric for the review.

llvm-svn: 169142

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

llvm-svn: 169111

Assertion failed: (TopRPTracker.getPos() == RegionBegin && "bad initial Top tracker").
rdar://12790302.

llvm-svn: 169072

Assertion failed: (VNI && "No value to read by operand")
rdar://12790267.

llvm-svn: 169071

Assertion failed: (itr != mi2iMap.end() && "Instruction not found in maps.")
rdar://12777252.

llvm-svn: 169070

assert (RemainingInstrs == 0 && "Instruction count mismatch!")

rdar://12776937.

llvm-svn: 169069

The TwoAddressInstructionPass takes the machine code out of SSA form by
expanding REG_SEQUENCE instructions into copies. It is no longer
necessary to rewrite the registers used by a REG_SEQUENCE instruction
because the new coalescer algorithm can do it now.

REG_SEQUENCE is just converted to a sequence of sub-register copies now.

llvm-svn: 169067

part of the compile unit CU and start separating out information into
the various sections that will be pulled out later.

WIP.

llvm-svn: 169061

MachineCopyPropagation doesn't understand super-register liveness well
enough to be able to remove implicit defs of super-registers.

This fixes a problem in ARM/2012-01-26-CopyPropKills.ll that is exposed
by an future TwoAddressInstructionPass change. The KILL instructions are
removed before the machine code is emitted.

llvm-svn: 169060

The original patch removed a bunch of code that the SjLjEHPrepare pass placed
into the entry block if all of the landing pads were removed during the
CodeGenPrepare class. The more natural way of doing things is to run the CGP
*before* we run the SjLjEHPrepare pass.

Make it so!

llvm-svn: 169044

llvm-svn: 168952

llvm-svn: 168932

This was found by MSVC10's STL debug mode on a test from the test suite. Sadly
std::is_heap isn't standard so there is no way to assert this without writing
our own heap verify, which looks like overkill to me.

llvm-svn: 168885

If we need to split the operand of a VSELECT, it must be the mask operand. We
split the entire VSELECT operand with EXTRACT_SUBVECTOR.

llvm-svn: 168883

Allow targets to prefer TypeSplitVector over TypePromoteInteger when computing the legalization method for vectors

For some targets, it is desirable to prefer scalarizing <N x i1> instead of promoting to a larger legal type, such as <N x i32>.

llvm-svn: 168882

This saves a bit of memory.

llvm-svn: 168852

This could cause miscompilations in targets where sub-register
composition is not always idempotent (ARM).

<rdar://problem/12758887>

llvm-svn: 168837

llvm-svn: 168832

No functional change, just moved header files.

Targets can inject custom passes between register allocation and
rewriting. This makes it possible to tweak the register allocation
before rewriting, using the full global interference checking available
from LiveRegMatrix.

llvm-svn: 168806

This is a simple, cheap infrastructure for analyzing the shape of a
DAG. It recognizes uniform DAGs that take the shape of bottom-up
subtrees, such as the included matrix multiplication example. This is
useful for heuristics that balance register pressure with ILP. Two
canonical expressions of the heuristic are implemented in scheduling
modes: -misched-ilpmin and -misched-ilpmax.

llvm-svn: 168773

llvm-svn: 168772

This fixes a hole in the "cheap" alias analysis logic implemented within
the DAG builder itself, regardless of whether proper alias analysis is
enabled. It now handles this pattern produced by LSR+CodeGenPrepare.

%sunkaddr1 = ptrtoint * %obj to i64
%sunkaddr2 = add i64 %sunkaddr1, %lsr.iv
%sunkaddr3 = inttoptr i64 %sunkaddr2 to i32*
store i32 %v, i32* %sunkaddr3

llvm-svn: 168768

llvm-svn: 168767

The *Impl class no longer serves a purpose now that the super-class
implementation is in CodeGen.

llvm-svn: 168759

The Target library is not allowed to depend on the large CodeGen
library, but the TRI and TII classes provide abstract interfaces that
require both caller and callee to link to CodeGen.

The implementation files for these classes provide default
implementations of some of the hooks. These methods may need to
reference CodeGen, so they belong in that library.

We already have a number of methods implemented in the
TargetInstrInfoImpl sub-class because of that. I will merge that class
into the parent next.

llvm-svn: 168758