This automatically passes a context pointer to MI->addOperand().

llvm-svn: 170711

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

This saves a bit of memory.

llvm-svn: 168852

llvm-svn: 168751

r168627), we no longer need to call the freezeReservedRegs() function a second
time.  Previously, this pass was conservatively adding the FP to the set of
reserved registers, requiring the second update to the reserved registers.
rdar://12719844

llvm-svn: 168631

register masks.  This is an obvious and necessary fix for a soon to be committed
patch.  No test case possible at this time.  Reviewed by Jakob.

llvm-svn: 167498

type MachineInstr* and MachineBasicBlock::iterator.

llvm-svn: 167088

This is just as fast, and it makes it possible to avoid leaking the
UsedPhysRegs BitVector implementation through
MachineRegisterInfo::addPhysRegsUsed().

llvm-svn: 166083

Clients can use the equivalent functions in MRI.

llvm-svn: 165990

Based on CR feedback from r162301 and Craig Topper's refactoring in r162347
here are a few other places that could use the same API (& in one instance drop
a Function.h dependency).

llvm-svn: 162367

That particular optimization was probably premature anyway.

llvm-svn: 161541

Allow targets to access this API. It's required for RegisterPressure.

llvm-svn: 158102

No functional change intended.

Sorry for the churn. The iterator classes are supposed to help avoid
giant commits like this one in the future. The TableGen-produced
register lists are getting quite large, and it may be necessary to
change the table representation.

This makes it possible to do so without changing all clients (again).

llvm-svn: 157854

MCRegAliasIterator can include Reg itself in the list.

llvm-svn: 157848

This should unbreak llvm-x86_64-linux.

llvm-svn: 156778

RAFast must add an <imp-def> operand when it is rewriting a sub-register
def that isn't a read-modify-write.

llvm-svn: 156777

This nicely handles the most common case of virtual register sets, but
also handles anticipated cases where we will map pointers to IDs.

The goal is not to develop a completely generic SparseSet
template. Instead we want to handle the expected uses within llvm
without any template antics in the client code. I'm adding a bit of
template nastiness here, and some assumption about expected usage in
order to make the client code very clean.

The expected common uses cases I'm designing for:
- integer keys that need to be reindexed, and may map to additional
  data
- densely numbered objects where we want pointer keys because no
  number->object map exists.

llvm-svn: 155227

llvm-svn: 152301

llvm-svn: 152001

llvm-svn: 151167

This makes RAFast 4% faster, and it gets rid of the dodgy DenseMap
iteration.

This also revealed that RAFast would sometimes dereference DenseMap
iterators after erasing other elements from the map. That does seem to
work in the current DenseMap implementation, but SparseSet doesn't allow
it.

llvm-svn: 151111

Passes after RegAlloc should be able to rely on MRI->getNumVirtRegs() == 0.
This makes sharing code for pre/postRA passes more robust.
Now, to check if a pass is running before the RA pipeline begins, use MRI->isSSA().
To check if a pass is running after the RA pipeline ends, use !MRI->getNumVirtRegs().

PEI resets virtual regs when it's done scavenging.

PTX will either have to provide its own PEI pass or assign physregs.

llvm-svn: 151032

MRI keeps track of which physregs have been used. Make sure it gets
updated with all the regmask-clobbered registers.

Delete the closePhysRegsUsed() function which isn't necessary.

llvm-svn: 150830

Creates a configurable regalloc pipeline.

Ensure specific llc options do what they say and nothing more: -reglloc=... has no effect other than selecting the allocator pass itself. This patch introduces a new umbrella flag, "-optimize-regalloc", to enable/disable the optimizing regalloc "superpass". This allows for example testing coalscing and scheduling under -O0 or vice-versa.

When a CodeGen pass requires the MachineFunction to have a particular property, we need to explicitly define that property so it can be directly queried rather than naming a specific Pass. For example, to check for SSA, use MRI->isSSA, not addRequired<PHIElimination>.

CodeGen transformation passes are never "required" as an analysis

ProcessImplicitDefs does not require LiveVariables.

We have a plan to massively simplify some of the early passes within the regalloc superpass.

llvm-svn: 150226

llvm-svn: 149398

This removes implicit assumption about the form of MI coming into regalloc. In particular, it should be independent of ProcessImplicitDefs which will eventually become a standard part of coming out of SSA--unless we simply can eliminate IMPLICIT_DEF completely. Current unit tests expose this once I remove incidental pass ordering restrictions.

This is not a final fix. Just a temporary workaround until I figure out the right way.

llvm-svn: 149360

The register allocators don't currently support adding reserved
registers while they are running.  Extend the MRI API to keep track of
the set of reserved registers when register allocation started.

Target hooks like hasFP() and needsStackRealignment() can look at this
set to avoid reserving more registers during register allocation.

llvm-svn: 147577

generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.

For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.

llvm-svn: 146026

before the clobber so that we copy the value if needed.

Fixes pr11415.

llvm-svn: 145056

llvm-svn: 144696

asm.c:2:7: error: ran out of registers during register allocation
  asm(""::"r"(0), "r"(1), "r"(2), "r"(3), "r"(4), "r"(5), "r"(6), "r"(7), "r"(8), "r"(9));
        ^

llvm-svn: 134310

sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.

llvm-svn: 134021

llvm-svn: 134013

llvm-svn: 133569

There could be more than one DBG_VALUE instructions for variables where all of them have offset based on one register.

llvm-svn: 133560

In particular, don't spill dirty registers only to satisfy a hint. It is
not worth it.

The attached test case provides an example where the fast allocator
would spill a register when other registers are available.

llvm-svn: 132900

When compiling a program with lots of small functions like
483.xalancbmk, this makes RAFast 11% faster.

Add some comments to clarify the difference between unallocatable and
reserved registers. It's quite subtle.

The fast register allocator depends on EFLAGS' not being allocatable on
x86. That way it can completely avoid tracking liveness, and it won't
mind when there are multiple uses of a single def.

llvm-svn: 132514

This saves two virtual function calls and an Allocatable BitVector test,
making RAFast run 2% faster.

llvm-svn: 132471

llvm-svn: 129970

registers for fast allocation a different way. This has us updating
used registers only when we're using that exact register.

Fixes rdar://9207598

llvm-svn: 129711