Machine sink could potentially sink instructions into a block where the physical
authorBill Wendling <isanbard@gmail.com>
Thu, 3 Jun 2010 07:54:20 +0000 (07:54 +0000)
committerBill Wendling <isanbard@gmail.com>
Thu, 3 Jun 2010 07:54:20 +0000 (07:54 +0000)
commit869d60d39d579b2051a8e34f460de72f071c2172
tree7323ab2430a9c2ff27409b43b925cb111ab8e529
parent8ef297e9451b678868fe08a249a5d1d101ee84bc
Machine sink could potentially sink instructions into a block where the physical
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105387 91177308-0d34-0410-b5e6-96231b3b80d8
lib/CodeGen/MachineSink.cpp
test/CodeGen/X86/MachineSink-CritEdge.ll
test/CodeGen/X86/sink-hoist.ll