Grammar.

llvm-svn: 195181

Represent RegUnit liveness with LiveRange instance

Previously LiveInterval has been used, but having a spill weight and
register number is unnecessary for a register unit.

llvm-svn: 192397

Rename LiveRange to LiveInterval::Segment

The Segment struct contains a single interval; multiple instances of this struct
are used to construct a live range, but the struct is not a live range by
i

Rename LiveRange to LiveInterval::Segment

The Segment struct contains a single interval; multiple instances of this struct
are used to construct a live range, but the struct is not a live range by
itself.

llvm-svn: 192392

show more ...

Debug info: Fix PR16736 and rdar://problem/14990587.
A DBG_VALUE is register-indirect iff the first operand is a register
_and_ the second operand is an immediate.

llvm-svn: 190821

Track new virtual registers by register number.

Track new virtual registers by register number, rather than by the live
interval created for them. This is the first step in separating the
creation o

Track new virtual registers by register number.

Track new virtual registers by register number, rather than by the live
interval created for them. This is the first step in separating the
creation of new virtual registers and new live intervals. Eventually
live intervals will be created and populated on demand after the virtual
registers have been created and used in instructions.

llvm-svn: 188434

show more ...

Reapply an improved version of r180816/180817.

Change the informal convention of DBG_VALUE machine instructions so that
we can express a register-indirect address with an offset of 0.
The old conven

Reapply an improved version of r180816/180817.

Change the informal convention of DBG_VALUE machine instructions so that
we can express a register-indirect address with an offset of 0.
The old convention was that a DBG_VALUE is a register-indirect value if
the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE
is register-indirect if the first operand is a register and the second
operand is an immediate. For plain register values the combination reg,
reg is used. MachineInstrBuilder::BuildMI knows how to build the new
DBG_VALUES.

rdar://problem/13658587

llvm-svn: 185966

show more ...

Debug Info: Simplify Frame Index handling in DBG_VALUE Machine Instructions

Rather than using the full power of target-specific addressing modes in
DBG_VALUEs with Frame Indicies, simply use Frame I

Debug Info: Simplify Frame Index handling in DBG_VALUE Machine Instructions

Rather than using the full power of target-specific addressing modes in
DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This
reduces the complexity of debug info handling down to two
representations of values (reg+offset and frame index+offset) rather
than three or four.

Ideally we could ensure that frame indicies had been eliminated by the
time we reached an assembly or dwarf generation, but I haven't spent the
time to figure out where the FIs are leaking through into that & whether
there's a good place to convert them. Some FI+offset=>reg+offset
conversion is done (see PrologEpilogInserter, for example) which is
necessary for some SelectionDAG assumptions about registers, I believe,
but it might be possible to make this a more thorough conversion &
ensure there are no remaining FIs no matter how instruction selection
is performed.

llvm-svn: 184066

show more ...

Temporarily revert "Change the informal convention of DBG_VALUE so that we can express a"
because it breaks some buildbots.

This reverts commit 180816.

llvm-svn: 180819

Change the informal convention of DBG_VALUE so that we can express a
register-indirect address with an offset of 0.
It used to be that a DBG_VALUE is a register-indirect value if the offset
(operand

Change the informal convention of DBG_VALUE so that we can express a
register-indirect address with an offset of 0.
It used to be that a DBG_VALUE is a register-indirect value if the offset
(operand 1) is nonzero. The new convention is that a DBG_VALUE is
register-indirect if the first operand is a register and the second
operand is an immediate. For plain registers use the combination reg, reg.

rdar://problem/13658587

llvm-svn: 180816

show more ...

Clean up LDV, no functionality change.

Remove dead functions: renameRegister
Move private member variables from LDV to Impl
Remove ssp/uwtable from testing case

llvm-svn: 175072

Fix comment.

llvm-svn: 175024

Debug Info: LiveDebugVarible can remove DBG_VALUEs, make sure we emit them back.

RegisterCoalescer used to depend on LiveDebugVariable. LDV removes DBG_VALUEs
without emitting them at the end.

We f

Debug Info: LiveDebugVarible can remove DBG_VALUEs, make sure we emit them back.

RegisterCoalescer used to depend on LiveDebugVariable. LDV removes DBG_VALUEs
without emitting them at the end.

We fix this by removing LDV from RegisterCoalescer. Also add an assertion to
make sure we call emitDebugValues if DBG_VALUEs are removed at
runOnMachineFunction.

rdar://problem/13183203
Reviewed by Andy & Jakob

llvm-svn: 175023

show more ...

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

show more ...

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

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

show more ...

Make the LiveRegMatrix analysis available to targets.

No functional change, just moved header files.

Targets can inject custom passes between register allocation and
rewriting. This makes it possib

Make the LiveRegMatrix analysis available to targets.

No functional change, just moved header files.

Targets can inject custom passes between register allocation and
rewriting. This makes it possible to tweak the register allocation
before rewriting, using the full global interference checking available
from LiveRegMatrix.

llvm-svn: 168806

show more ...

Tidy up a few more uses of MF.getFunction()->getName().

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

Tidy up a few more uses of MF.getFunction()->getName().

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

show more ...

Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp and
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.

The reasoning is because the DebugInfo module is simply an interface to

Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp and
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.

The reasoning is because the DebugInfo module is simply an interface to the
debug info MDNodes and has nothing to do with analysis.

llvm-svn: 159312

show more ...

Don't depend on live ranges being present.

DBG_VALUE instructions could be referring to non-existing virtual
registers.

llvm-svn: 159020

Use regunit liveness to guide LiveDebugVariables.

This should produce the same results as using physreg liveness directly.

llvm-svn: 159009

Handle NewReg==OldReg in renameRegister().

This can happen when widening a virtual register to a super-register
class.

llvm-svn: 156867

Tabs.

llvm-svn: 152842

Typo.

llvm-svn: 152841

Add bundle aware API for querying instruction properties and switch the code
generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.

For properties like mayL

Add bundle aware API for querying instruction properties and switch the code
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

show more ...

Rename SlotIndexes to match how they are used.

The old naming scheme (load/use/def/store) can be traced back to an old
linear scan article, but the names don't match how slots are actually
used.

Th

Rename SlotIndexes to match how they are used.

The old naming scheme (load/use/def/store) can be traced back to an old
linear scan article, but the names don't match how slots are actually
used.

The load and store slots are not needed after the deferred spill code
insertion framework was deleted.

The use and def slots don't make any sense because we are using
half-open intervals as is customary in C code, but the names suggest
closed intervals. In reality, these slots were used to distinguish
early-clobber defs from normal defs.

The new naming scheme also has 4 slots, but the names match how the
slots are really used. This is a purely mechanical renaming, but some
of the code makes a lot more sense now.

llvm-svn: 144503

show more ...

Stop tracking spill slot uses in VirtRegMap.

Nobody cared, StackSlotColoring scans the instructions to find used stack
slots.

llvm-svn: 144485