This would previously get reported as the misleading "Virtual register
def doesn't dominate all uses."

llvm-svn: 159460

Verify that all paths from the entry block to a virtual register read
pass through a def. Enable this check even when MRI->isSSA() is false.

Verify that the live range of a virtual register is live out of all
predecessor blocks, even for PHI-values.

This requires that PHIElimination sometimes inserts IMPLICIT_DEF
instruction in predecessor blocks.

llvm-svn: 159150

llvm-svn: 159039

Deterministically enumerate the virtual registers instead.

llvm-svn: 158872

the last instruction of a basic block.

llvm-svn: 158468

Move terminator machine verification to check MachineBasicBlock::instr_iterator instead of MBB::iterator

llvm-svn: 158154

Bundles should be treated as one atomic transaction when checking
liveness. That is how the register allocator (and VLIW targets) treats
bundles.

llvm-svn: 158116

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

llvm-svn: 157640

Make sure useless (def-only) intervals also get verified.

llvm-svn: 157000

The getPointerRegClass() hook can return register classes that depend on
the calling convention of the current function (ptr_rc_tailcall).

So far, we have been able to infer the calling convention from the
subtarget alone, but as we add support for multiple calling conventions
per target, that no longer works.

Patch by Yiannis Tsiouris!

llvm-svn: 156328

The late scheduler depends on accurate liveness information if it is
breaking anti-dependencies, so we should be able to verify it.

Relax the terminator checking in the machine code verifier so it can
handle the basic blocks created by if conversion.

llvm-svn: 153614

Extract the liveness verification into its own method.

This makes it possible to run the machine code verifier after liveness
information is no longer required to be valid.

llvm-svn: 153596

llvm-svn: 152460

Somehow we never verified SSA dominance before.

llvm-svn: 152458

llvm-svn: 152457

llvm-svn: 152016

Extract a base class and provide four specific sub-classes for iterating
over const/non-const bundles/instructions.

This eliminates the mystery bool constructor argument.

llvm-svn: 151684

llvm-svn: 151607

After the SlotIndex slot names were updated, it is possible to apply
stricter checks to live intervals.

Also treat bundles as bags of operands when checking live intervals.

llvm-svn: 151531

llvm-svn: 150496

  to finalize MI bundles (i.e. add BUNDLE instruction and computing register def
  and use lists of the BUNDLE instruction) and a pass to unpack bundles.
- Teach more of MachineBasic and MachineInstr methods to be bundle aware.
- Switch Thumb2 IT block to MI bundles and delete the hazard recognizer hack to
  prevent IT blocks from being broken apart.

llvm-svn: 146542

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

llvm-svn: 144648

llvm-svn: 144517

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

PhysReg operands are not allowed to have sub-register indices at all.

For virtual registers with sub-reg indices, check that all registers in
the register class support the sub-reg index.

llvm-svn: 141220

This exposes a -segmented-stacks bug.

llvm-svn: 140429

This is still a hack until we can teach tblgen to generate the
optional CPSR operand rather than an implicit CPSR def. But the
strangeness is now limited to the selection DAG. ADD/SUB MI's no
longer have implicit CPSR defs, nor do we allow flag setting variants
of these opcodes in machine code. There are several corner cases to
consider, and getting one wrong would previously lead to nasty
miscompilation. It's not the first time I've debugged one, so this
time I added enough verification to ensure it won't happen again.

llvm-svn: 140228

There is only one legitimate use remaining, in addIntervalsForSpills().
All other calls to hasPHIKill() are only used to update PHIKill flags.

The addIntervalsForSpills() function is part of the old spilling
framework, only used by linearscan.

llvm-svn: 139783

The ARM target depends on CPSR liveness being tracked after register
allocation.

llvm-svn: 136548

This includes registers like EFLAGS and ST0-ST7. We don't check for
liveness issues in the verifier and scavenger because registers will
never be allocated from these classes.

While in SSA form, we do care about the liveness of unallocatable
unreserved registers. Liveness of EFLAGS and ST0 neds to be correct for
MachineDCE and MachineSinking.

llvm-svn: 136541

llvm-svn: 136535

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: 133944

No functional change.

llvm-svn: 132455

on CodeGen/X86/2007-05-07-InvokeSRet.ll. There is probably a bug here that was
fixed by r128961, but since there is no test or reference to a source file I have
to revert it.

llvm-svn: 131618

landing pad as its successor.

SjLj exception handling jumps to the correct landing pad via a switch statement
that's generated right before code-gen. Loosen the constraint in the machine
instruction verifier to allow for this. Note, this isn't the most rigorous check
since we cannot determine where that switch statement came from. But it's
marginally better than turning this check off when SjLj exceptions are used.
<rdar://problem/9187612>

llvm-svn: 130881

Treat the landing pad as a normal successor when that happens.

llvm-svn: 128961

llvm-svn: 128643