Added a linearscan register allocation optimization. When the register allocator spill an interval with multiple uses in the same basic block, it creates a different virtual register for each of the reloads. e.g.

	%reg1498<def> = MOV32rm %reg1024, 1, %reg0, 12, %reg0, Mem:LD(4,4) [sunkaddr39 + 0]
        %reg1506<def> = MOV32rm %reg1024, 1, %reg0, 8, %reg0, Mem:LD(4,4) [sunkaddr42 + 0]
        %reg1486<def> = MOV32rr %reg1506
        %reg1486<def> = XOR32rr %reg1486, %reg1498, %EFLAGS<imp-def,dead>
        %reg1510<def> = MOV32rm %reg1024, 1, %reg0, 4, %reg0, Mem:LD(4,4) [sunkaddr45 + 0]

=>

        %reg1498<def> = MOV32rm %reg2036, 1, %reg0, 12, %reg0, Mem:LD(4,4) [sunkaddr39 + 0]
        %reg1506<def> = MOV32rm %reg2037, 1, %reg0, 8, %reg0, Mem:LD(4,4) [sunkaddr42 + 0]
        %reg1486<def> = MOV32rr %reg1506
        %reg1486<def> = XOR32rr %reg1486, %reg1498, %EFLAGS<imp-def,dead>
        %reg1510<def> = MOV32rm %reg2038, 1, %reg0, 4, %reg0, Mem:LD(4,4) [sunkaddr45 + 0]

From linearscan's point of view, each of reg2036, 2037, and 2038 are separate registers, each is "killed" after a single use. The reloaded register is available and it's often clobbered right away. e.g. In thise case reg1498 is allocated EAX while reg2036 is allocated RAX. This means we end up with multiple reloads from the same stack slot in the same basic block.

Now linearscan recognize there are other reloads from same SS in the same BB. So it'll "downgrade" RAX (and its aliases) after reg2036 is allocated until the next reload (reg2037) is done. This greatly increase the likihood reloads from SS are reused.

This speeds up sha1 from OpenSSL by 5.8%. It is also an across the board win for SPEC2000 and 2006.

llvm-svn: 69585

llvm-svn: 69583

pointer type, make sure that the pointer size is a valid sequential index type.

llvm-svn: 69574

freeMachineCodeForFunction was never called.

llvm-svn: 69531

bigger than the vector element type, turn checking
of the operand type back on again, appropriately
adjusted.

llvm-svn: 69516

patch by Jakob Stoklund Olesen!

llvm-svn: 69472

type as the vector element type: allow them to be of
a wider integer type than the element type all the way
through the system, and not just as far as LegalizeDAG.
This should be safe because it used to be this way
(the old type legalizer would produce such nodes), so
backends should be able to handle it.  In fact only
targets which have legal vector types with an illegal
promoted element type will ever see this (eg: <4 x i16>
on ppc).  This fixes a regression with the new type
legalizer (vec_splat.ll).  Also, treat SCALAR_TO_VECTOR
the same as BUILD_VECTOR.  After all, it is just a
special case of BUILD_VECTOR.

llvm-svn: 69467

instead of allocating and leaking new SCEVCouldNotCompute objects.

llvm-svn: 69452

llvm-svn: 69451

llvm-svn: 69450

Add a new LiveInterval::overlaps(). It checks if the live interval overlaps a range specified by [Start, End).

llvm-svn: 69434

llvm-svn: 69417

my earlier patch to this code only fixed half of it.

llvm-svn: 69408

llvm-svn: 69402

llvm-svn: 69394

llvm-svn: 69382

llvm-svn: 69381

punctuation.  No functional changes.

llvm-svn: 69378

for ARM.  Patch by Sandeep Patel.

llvm-svn: 69371

Use a safer iterator interface and get rid of std C++ library misuse.
This fixes a --enable-expensive-checks problem.

llvm-svn: 69353

leaq	foo@TLSGD(%rip), %rdi

as part of the instruction sequence. Using a register other than %rdi and then
copying it to %rdi is not valid.

llvm-svn: 69350

llvm-svn: 69347

regression in 403.gcc in PIC_CODEGEN=1 and DISABLE_LTO=1
mode.

llvm-svn: 69344

register is available and when it's profitable.

e.g.
     xorq  %r12<kill>, %r13
     addq  %rax, -184(%rbp)
     addq  %r13, -184(%rbp)
==>
     xorq  %r12<kill>, %r13
     movq  -184(%rbp), %r12
     addq  %rax, %r12
     addq  %r13, %r12
     movq  %r12, -184(%rbp)

Two more instructions, but fewer memory accesses. It can also open up
opportunities for more optimizations.

llvm-svn: 69341

matter, because this instruction isn't generated until after
things that care.

llvm-svn: 69336

present, but it's inconsistent.

llvm-svn: 69335

this fixes a crash on CodeGen/Generic/externally_available.ll
on ppc hosts.  Thanks to Nicholas L for pointing this out.

llvm-svn: 69333

to get the correct answer for pointer types.

llvm-svn: 69321

locks must be matched with unlocks.  Also, use calloc to allocate the
block so that it is properly zero'd.  Thanks to Nick Kledzik for
tracking this down.

llvm-svn: 69314

incoming edges for a block with many predecessors.

llvm-svn: 69312

llvm-svn: 69310

add dependencies on nodes with exactly one successor which is a
COPY_TO_REGCLASS node. In the case that the copy is coalesced
away, the dependence should be on the user of the copy, rather
than the copy itself.

llvm-svn: 69309

as INSERT_SUBREG instructions in the list-burr scheduler.

llvm-svn: 69308

size from the integer, requiring zero extension or truncation. Don't
create ZExtInsts with pointer types. This fixes a regression in
consumer-jpeg.

llvm-svn: 69307

Do not treat beginning of inlined scope as beginning of normal function scope if the location info is missing.

Insetad of doing ...
if (inlined_subroutine && known_location)
  DW_TAG_inline_subroutine
else
  DW_TAG_subprogram

do

if (inlined_subroutine) {
 if (known_location)
   DW_TAG_inline_subroutine
} else {
 DW_TAG_subprogram
}

llvm-svn: 69300

targets with pointers larger than 64 bits, due to the code not
yet being APInt clean.

llvm-svn: 69296

optimizer, which just happen to frequently involve optimizing GEPs.

llvm-svn: 69295

not create ICmpInsts with operands of different types. This fixes
a regression in Applications/d/make_dparser.

llvm-svn: 69294

and ptrtoint-of-inttoptr expressions. This fixes a regression in 300.twolf.

llvm-svn: 69293

since the operand is always a constant.

llvm-svn: 69291