maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
280,954 Commits 23 Branches 0 Tags 2.2 GiB
Commit Graph

6 Commits

Author SHA1 Message Date
Tim Northover 6833e3fd75 X86: Stop LEA64_32r doing unspeakable things to its arguments. 
Previously LEA64_32r went through virtually the entire backend thinking it was
using 32-bit registers until its blissful illusions were cruelly snatched away
by MCInstLower and 64-bit equivalents were substituted at the last minute.

This patch makes it behave normally, and take 64-bit registers as sources all
the way through. Previous uses (for 32-bit arithmetic) are accommodated via
SUBREG_TO_REG instructions which make the types and classes agree properly.

llvm-svn: 183693
 2013-06-10 20:43:49 +00:00
Bill Wendling e41e40f689 - Reapply r106066 now that the bzip2 build regression has been fixed. 
- 2010-06-25-CoalescerSubRegDefDead.ll is the testcase for r106878.

llvm-svn: 106880
 2010-06-25 20:48:10 +00:00
Daniel Dunbar ef5a4383ad Revert r106066, "Create a more targeted fix for not sinking instructions into a range where it"... it causes bzip2 to be miscompiled by Clang. 
Conflicts:

	lib/CodeGen/MachineSink.cpp

llvm-svn: 106614
 2010-06-23 00:48:25 +00:00
Bill Wendling 8c0cf0994d Create a more targeted fix for not sinking instructions into a range where it 
will conflict with another live range. The place which creates this scenerio is
the code in X86 that lowers a select instruction by splitting the MBBs. This
eliminates the need to check from the bottom up in an MBB for live pregs.

llvm-svn: 106066
 2010-06-15 23:46:31 +00:00
Bill Wendling f82aea634c 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.

llvm-svn: 105387
 2010-06-03 07:54:20 +00:00
Jakob Stoklund Olesen dc6d42dbf8 Add test case for machine-sink on critical edges 
llvm-svn: 101416
 2010-04-15 23:19:16 +00:00