a condition's grouping. Every other use of Allocatable.test(Hint) groups it the
same way as it is indented, so move the parentheses to agree with that
grouping.

llvm-svn: 103869

llvm-svn: 103868

When working top-down in a basic block, substituting physregs for virtregs, the use-def chains are kept up to date. That means we can recognize a virtreg kill by the use-def chain becoming empty.

This makes the fast allocator independent of incoming kill flags.

llvm-svn: 103866

inliner did in r103653. Why does the always inliner even bother with cost
estimates anyways?

llvm-svn: 103858

llvm-svn: 103857

llvm-svn: 103855

allow target to override it in order to map register classes to illegal
but synthesizable types. e.g. v4i64, v8i64 for ARM / NEON.

llvm-svn: 103854

llvm-svn: 103851

llvm-svn: 103850

instructions.

e.g.
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1027<def> = EXTRACT_SUBREG %reg1026, 6
%reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5
...
%reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12

After REG_SEQUENCE is eliminated, we are left with:

%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6
%reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5

The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't
know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the
target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger
sub-register (or combined to be reg1026 itself as is the case here). If it is possible, 
it will be able to replace references of reg1026 with reg1029 + the larger sub-register
index.

llvm-svn: 103835

llvm-svn: 103833

setting kill flags.

llvm-svn: 103832

llvm-svn: 103831

llvm-svn: 103830

replace the check with the appropriate predicate. Modify the testcase to reflect
the correct code. (It should be saving callee-saved registers on the stack
allocated by the calling fuction.)

llvm-svn: 103829

llvm-svn: 103828

llvm-svn: 103827

llvm-svn: 103826

of "has calls". That's probably wrong, but it needs further
investigation. Revert to the original behavior until this is settled.

llvm-svn: 103824

llvm-svn: 103823

llvm-svn: 103822

llvm-svn: 103821

llvm-svn: 103820

stack.

llvm-svn: 103813

llvm-svn: 103808

llvm-svn: 103807

llvm-svn: 103806

while debugging what's mishandled about them in the post-RA pass.

llvm-svn: 103805

llvm-svn: 103804

the variable actually tracks.

N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.

llvm-svn: 103802

used more than once. If ISel had put a kill flag on one of them,
it's not valid to transfer the kill flag to each new instance.

llvm-svn: 103799

llvm-svn: 103798

- Kill is implicit when use and def registers are identical.
- Only virtual registers can differ.

Add a -verify-fast-regalloc to run the verifier before the fast allocator.

llvm-svn: 103797

argument, like "int $4", to not get an Assertion error.

llvm-svn: 103791

llvm-svn: 103790

used to replace a normal relocation, not a reference to a GOT entry.

llvm-svn: 103789

This adds extra security against using clobbered physregs, and it adds kill
markers to physreg uses.

llvm-svn: 103784

llvm-svn: 103778

control barriers, not memory ordering barriers.

llvm-svn: 103777

llvm-svn: 103776