llvm-svn: 119374

(and likely) wrong about anyhow.

llvm-svn: 119320

Use amazing new function call technology instead of writing identical code in
multiple places.

This fixes PR8604.

llvm-svn: 119306

The live range of a register defined by an early clobber starts at the use slot,
not the def slot.

Except when it is an early clobber tied to a use operand. Then it starts at the
def slot like a standard def.

llvm-svn: 119305

This reverts r119183 which borke the buildbots.

llvm-svn: 119270

iterator, not TII->OptimizeCompareInstr.

llvm-svn: 119186

The live range of a register defined by an early clobber starts at the use slot,
not the def slot.

llvm-svn: 119183

live ranges for the spill register are also defined at the use slot instead of
the normal def slot.

This fixes PR8612 for the inline spiller. A use was being allocated to the same
register as a spilled early clobber def.

This problem exists in all the spillers. A fix for the standard spiller is
forthcoming.

llvm-svn: 119182

First step of huge frame-related refactoring: move emit{Prologue,Epilogue} out of TargetRegisterInfo to TargetFrameInfo, which is definitely much better suitable place

llvm-svn: 119097

since it is trivial and will be shared between ppc and x86.
This substantially simplifies the X86 backend also.

llvm-svn: 119089

llvm-svn: 118940

llvm-svn: 118913

catastrophic compilation time in the event of unreasonable LLVM
IR. Code quality is a separate issue--someone upstream needs to do a
better job of reducing to llvm.memcpy. If the situation can be reproduced with
any supported frontend, then it will be a separate bug.

llvm-svn: 118904

llvm-svn: 118896

llvm-svn: 118883

llvm-svn: 118803

it makes no sense for allocation_order iterators to visit reserved regs.
The inline spiller depends on AliasAnalysis.
Manage the Query state to avoid uninitialized or stale results.

llvm-svn: 118800

llvm-svn: 118789

superceded by SplitKit.

llvm-svn: 118754

This is the first small step towards using closed intervals for liveness instead
of the half-open intervals we're using now.

We want to be able to distinguish between a SlotIndex that represents a variable
being live-out of a basic block, and an index representing a variable live-in to
its successor.

That requires two separate indexes between blocks. One for live-outs and one for
live-ins.

With this change, getMBBEndIdx(MBB).getPrevSlot() becomes stable so it stays
greater than any instructions inserted at the end of MBB.

llvm-svn: 118747

llvm-svn: 118742

constant loads.

llvm-svn: 118741

Take care of special characters while creating named MDNode name to hold function specific local variable's info.
This fixes radar 8653152. I am checking in testcase as a separate check-in.

llvm-svn: 118726

Whenever splitting wants to insert a copy, it checks if the value can be
rematerialized cheaply instead.

Missing features:
- Delete instructions when all uses have been rematerialized.
- Truncate live ranges to the remaining uses after rematerialization.

llvm-svn: 118702

benchmarks hitting an assertion.
Adds LiveIntervalUnion::collectInterferingVRegs.
Fixes "late spilling" by checking for any unspillable live vregs among
all physReg aliases.

llvm-svn: 118701

llvm-svn: 118661

earlier. Implicit bool -> int conversions are evil!

llvm-svn: 118651

(retry now that the windows build is green)

llvm-svn: 118630

-Wnon-virtual-dtor.

llvm-svn: 118616

llvm-svn: 118613

llvm-svn: 118604

in order to fold it into a load.

llvm-svn: 118471

{i64, i64} from matching i128.

llvm-svn: 118465

handle cases in which a register is unavailable for spill code.
Adds LiveIntervalUnion::extract. While processing interferences on a
live virtual register, reuses the same Query object for each
physcial reg.

llvm-svn: 118423

llvm-svn: 118394

llvm-svn: 118342

to perform the copy, which may be of lots of memory [*].  It would be good if the
fall-back code generated something reasonable, i.e. did the copy in a loop, rather
than vast numbers of loads and stores.  Add a note about this.  Currently target
specific code seems to always kick in so this is more of a theoretical issue rather
than a practical one now that X86 has been fixed.
[*] It's amazing how often people pass mega-byte long arrays by copy...

llvm-svn: 118275

llvm-svn: 118254

they do :-(

llvm-svn: 118250

llvm-svn: 118249