When tail-merging multiple blocks, make sure to correctly update the live-in list on the merged block to correctly account for the live-outs of all the predecessors.  They might not be the same in all cases (the testcase I have involves a PHI node where one of the operands is an IMPLICIT_DEF).

Unfortunately, the testcase I have is large and confidential, so I don't have a test to commit at the moment; I'll see if I can come up with something smaller where this issue reproduces.

<rdar://problem/9716278>

llvm-svn: 134565

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

llvm-svn: 132988

sharp all or nothing transition when one extra predecessor was added. Now
we still test first ones for merging.

llvm-svn: 132974

llvm-svn: 132149

llvm-svn: 132148

llvm-svn: 131258

Re-enable branchfolding common code hoisting optimization. Fixed a liveness test bug and also taught it to update liveins.

llvm-svn: 131241

llvm-svn: 131235

markers. In some cases a register def is dead on one path, but not on
another.

This is passing Clang self-hosting.

llvm-svn: 131214

to provide a reduced testcase.

llvm-svn: 131176

at the start of basic blocks to their common predecessor. It's actually quite
common (e.g. about 50 times in JM/lencod) and has shown to be a nice code size
benefit. e.g.

        pushq   %rax
        testl   %edi, %edi
        jne     LBB0_2
## BB#1:
        xorb    %al, %al
        popq    %rdx
        ret
LBB0_2:
        xorb    %al, %al
        callq   _foo
        popq    %rdx
        ret

=>

        pushq   %rax
        xorb    %al, %al
        testl   %edi, %edi
        je      LBB0_2
## BB#1:
        callq   _foo
LBB0_2:
        popq    %rdx
        ret

rdar://9145558

llvm-svn: 131172

An exception is thrown via a call to _cxa_throw, which we don't expect to
return. Therefore, the "true" part of the invoke goes to a BB that has
'unreachable' as its only instruction. This is lowered into an empty MachineBB.
The landing pad for this invoke, however, is directly after the "true" MBB.
When the empty MBB is removed, the landing pad is directly below the BB with the
invoke call. The unconditional branch is removed and then the two blocks are
merged together.

The testcase is too big for a regression test.
<rdar://problem/9305728>

llvm-svn: 129965

llvm-svn: 126158

llvm-svn: 110460

llvm-svn: 110410

ID member as the sole unique type identifier.  Clean up APIs related to this change.

llvm-svn: 110396

llvm-svn: 106517

- This fixed a number of bugs in if-converter, tail merging, and post-allocation
  scheduler. If-converter now runs branch folding / tail merging first to
  maximize if-conversion opportunities.
- Also changed the t2IT instruction slightly. It now defines the ITSTATE
  register which is read by instructions in the IT block.
- Added Thumb2 specific hazard recognizer to ensure the scheduler doesn't
  change the instruction ordering in the IT block (since IT mask has been
  finalized). It also ensures no other instructions can be scheduled between
  instructions in the IT block.

This is not yet enabled.

llvm-svn: 106344

addresses a longstanding deficiency noted in many FIXMEs scattered
across all the targets.

This effectively moves the problem up one level, replacing eleven
FIXMEs in the targets with eight FIXMEs in CodeGen, plus one path
through FastISel where we actually supply a DebugLoc, fixing Radar
7421831.

llvm-svn: 106243

beneficial cases. See the changes in test/CodeGen/X86/tail-opts.ll and
test/CodeGen/ARM/ifcvt2.ll for details.

The fix is to change HashEndOfMBB to hash at most one instruction,
instead of trying to apply heuristics about when it will be profitable to
consider more than one instruction. The regular tail-merging heuristics
are already prepared to handle the same cases, and they're more precise.

Also, make test/CodeGen/ARM/ifcvt5.ll and
test/CodeGen/Thumb2/thumb2-branch.ll slightly more complex so that they
continue to test what they're intended to test.

And, this eliminates the problem in
test/CodeGen/Thumb2/2009-10-15-ITBlockBranch.ll, the testcase from
PR5204. Update it accordingly.

llvm-svn: 102907

folder to be tolerant of debug info following the
branch(es) at the end of a block.

llvm-svn: 100168

disabled for several months (since svn r88806) and no one noticed.  My fix
for pr6543 yesterday reenabled it, but broke the ARM port's code for using
TBB/TBH.  Rather than adding a target hook to disable merging for Thumb2 only,
I'm just taking this out.  It is not common to have identical jump tables,
the code we used to merge them was O(N^2), and it only helps code size, not
performance.

llvm-svn: 98977

llvm-svn: 98694

them with a counter.

llvm-svn: 98462

llvm-svn: 98181

llvm-svn: 98137

llvm-svn: 98108

llvm-svn: 98104

llvm-svn: 97938

llvm-svn: 97765

into TargetOpcodes.h.  #include the new TargetOpcodes.h
into MachineInstr.  Add new inline accessors (like isPHI())
to MachineInstr, and start using them throughout the 
codebase.

llvm-svn: 95687

1. MachineJumpTableInfo is now created lazily for a function the first time
   it actually makes a jump table instead of for every function.
2. The encoding of jump table entries is now described by the
   MachineJumpTableInfo::JTEntryKind enum.  This enum is determined by the
   TLI::getJumpTableEncoding() hook, instead of by lots of code scattered
   throughout the compiler that "knows" that jump table entries are always
   32-bits in pic mode (for example).
3. The size and alignment of jump table entries is now calculated based on
   their kind, instead of at machinefunction creation time.

Future work includes using the EntryKind in more places in the compiler,
eliminating other logic that "knows" the layout of jump tables in various
situations.

llvm-svn: 94470

Change errs() to dbgs().

llvm-svn: 92097

llvm-svn: 91477

llvm-svn: 91475

$ svn merge -c -91161 https://llvm.org/svn/llvm-project/llvm/trunk
--- Reverse-merging r91161 into '.':
U    lib/CodeGen/BranchFolding.cpp
U    lib/CodeGen/MachineBasicBlock.cpp
$ svn merge -c -91113 https://llvm.org/svn/llvm-project/llvm/trunk
--- Reverse-merging r91113 into '.':
G    lib/CodeGen/MachineBasicBlock.cpp
$ svn merge -c -91101 https://llvm.org/svn/llvm-project/llvm/trunk
--- Reverse-merging r91101 into '.':
U    include/llvm/CodeGen/MachineBasicBlock.h
G    lib/CodeGen/MachineBasicBlock.cpp
$ svn merge -c -91092 https://llvm.org/svn/llvm-project/llvm/trunk
--- Reverse-merging r91092 into '.':
G    include/llvm/CodeGen/MachineBasicBlock.h
G    lib/CodeGen/MachineBasicBlock.cpp

llvm-svn: 91376

branches only to a landing pad. Without this check, the compiler would go into
an infinite loop because the branch to a landing pad is an "abnormal" edge which
wasn't being taken into account.

This is the meat of that fix:

  if (!PrevBB.canFallThrough() && !MBB->BranchesToLandingPad(MBB)) {

The other stuff is simplification of the "branches to a landing pad" code.

llvm-svn: 91161

MachineBasicBlock::canFallThrough(), which is target-independent and more
thorough.

llvm-svn: 90634