in the MachineFunction class, renaming it to addLiveIn for consistency with
the same method in MachineBasicBlock.  Thanks for Anton for suggesting this.

llvm-svn: 69615

llvm-svn: 69613

llvm-svn: 69610

llvm-svn: 69607

- Find more reloads from SS.

llvm-svn: 69606

llvm-svn: 69605

now that errs() is properly non-buffered.

llvm-svn: 69602

llvm-svn: 69599

which include Functions, where it can be quite useful to use an
AssemblyAnnotationWriter.

llvm-svn: 69598

64 bit platforms when building with optimization.
So replace them by a hand-coded implementation.
This fixes PR3822.

llvm-svn: 69597

llvm-svn: 69596

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

llvm-svn: 69529

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

llvm-svn: 69516

value type union: this field was causing problems for
some compilers on 64 bit systems, presumably because
SimpleTy is 32 bits wide while the other fields are
64 bits wide.

llvm-svn: 69515

Fixes segfaults in some corner cases.

llvm-svn: 69494

llvm-svn: 69478

Turns out that doing this by hand is easier than using autoreconf:-).

llvm-svn: 69475

llvm-svn: 69474

llvm-svn: 69473

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

Configure was not actually regenerated, but the change last time only touched
this one line, so I'm being lazy and cheating by fixing it manually.

llvm-svn: 69453

instead of allocating and leaking new SCEVCouldNotCompute objects.

llvm-svn: 69452

llvm-svn: 69451

llvm-svn: 69450

llvm-svn: 69447

llvm-svn: 69446

building llvm.

llvm-svn: 69441

release build of llvm.

llvm-svn: 69440

llvm-svn: 69439

llvm-svn: 69438

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

llvm-svn: 69434

llvm-svn: 69417

way worked for me...

llvm-svn: 69414

for the optimization it's testing to kick in (although
it improves the code, getting rid of all spills).
I don't understand the optimization well enough to
rescue the test, so XFAILing.

llvm-svn: 69409

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

llvm-svn: 69408