registers it defines then interfere with an existing preg live range.

For instance, if we had something like these machine instructions:

BB#0
  ... = imul ... EFLAGS<imp-def,dead>
  test ..., EFLAGS<imp-def>
  jcc BB#2 EFLAGS<imp-use>

BB#1
  ... ; fallthrough to BB#2

BB#2
  ... ; No code that defines EFLAGS
  jcc ... EFLAGS<imp-use>

Machine sink will come along, see that imul implicitly defines EFLAGS, but
because it's "dead", it assumes that it can move imul into BB#2. But when it
does, imul's "dead" imp-def of EFLAGS is raised from the dead (a zombie) and
messes up the condition code for the jump (and pretty much anything else which
relies upon it being correct).

The solution is to know which pregs are live going into a basic block. However,
that information isn't calculated at this point. Nor does the LiveVariables pass
take into account non-allocatable physical registers. In lieu of this, we do a
*very* conservative pass through the basic block to determine if a preg is live
coming out of it.

llvm-svn: 105387

llvm-svn: 105379

expansion is the same as that used by LegalizeDAG.

The resulting code sucks in terms of performance/codesize on x86-32 for a
64-bit operation; I haven't looked into whether different expansions might be
better in general.

llvm-svn: 105378

This affects both llvm-gcc and clang.

llvm-svn: 105372

spills and reloads.

This means that a partial define of a register causes a reload so the other
parts of the register are preserved.

The reload can be prevented by adding an <imp-def> operand for the full
register. This is already done by the coalescer and live interval analysis where
relevant.

llvm-svn: 105369

register updates.

These operands tell the spiller that the other parts of the partially defined
register are don't-care, and a reload is not necessary.

llvm-svn: 105361

llvm-svn: 105359

instruction defines subregisters.

Any existing subreg indices on the original instruction are preserved or
composed with the new subreg index.

Also substitute multiple operands mentioning the original register by using the
new MachineInstr::substituteRegister() function. This is necessary because there
will soon be <imp-def> operands added to non read-modify-write partial
definitions. This instruction:

  %reg1234:foo = FLAP %reg1234<imp-def>

will reMaterialize(%reg3333, bar) like this:

  %reg3333:bar-foo = FLAP %reg333:bar<imp-def>

Finally, replace the TargetRegisterInfo pointer argument with a reference to
indicate that it cannot be NULL.

llvm-svn: 105358

llvm-svn: 105344

llvm-svn: 105340

and tidy up the comment describing it.

llvm-svn: 105339

Use local small vector.

llvm-svn: 105332

for debug information.

llvm-svn: 105324

backends and removes the virtual declaration. With that out of the way
I should be able to cleanup one backend at a time.

llvm-svn: 105321

llvm-svn: 105308

checked and it is safe to proceed with the changes.

llvm-svn: 105304

llvm-svn: 105300

The comment about ordering of subreg indices is no longer true.
This exposed a bug in the new substVirtReg method that is also fixed.

llvm-svn: 105294

llvm-svn: 105292

Radar 7927666.

llvm-svn: 105285

llvm-svn: 105283

llvm-svn: 105282

handle structs passed by value via an extract/insert pair, as a bitcast
won't work on a struct. rdar://7742824

llvm-svn: 105280

that are too large.  This causes the freebsd bootloader to be too
large apparently.

It's unclear if this should be an -Os or -Oz thing.  Thoughts welcome.

llvm-svn: 105228

llvm-svn: 105226

llvm-svn: 105168

llvm-svn: 105105

shouldn't have a TargetLoweringInfo member. And FunctionLoweringInfo::set
doesn't needs its EnableFastISel argument.

llvm-svn: 105101

llvm-svn: 105100

llvm-svn: 105095

llvm-svn: 105066

llvm-svn: 105065

llvm-svn: 105061

implementation that is correct for most targets. Tablegen will override where
needed.

Add MachineOperand::subst{Virt,Phys}Reg methods that correctly handle existing
subreg indices when sustituting registers.

llvm-svn: 104985

llvm-svn: 104953

This will help reduce the amount of casting required on 64-bit targets.

llvm-svn: 104911

optimization level.

This only really affects llc for now because both the llvm-gcc and clang front
ends override the default register allocator. I intend to remove that code later.

llvm-svn: 104904

an alloca() or an llvm.stackrestore(). rdar://8031573

llvm-svn: 104900

llvm-svn: 104897

llvm-svn: 104884