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

Patch by Howard Hinnant!

llvm-svn: 90365

running tail duplication when doing branch folding for if-conversion, and
we also want to be able to run tail duplication earlier to fix some
reg alloc problems.  Move the CanFallThrough function from BranchFolding
to MachineBasicBlock so that it can be shared by TailDuplication.

llvm-svn: 89904

Make tail duplication of indirect branches much more aggressive (for targets
that indicate that it is profitable), based on further experience with
this transformation.  I compiled 3 large applications with and without
this more aggressive tail duplication and measured minimal changes in code
size.  ("size" on Darwin seems to round the text size up to the nearest
page boundary, so I can only say that any code size increase was less than
one 4k page.) Radar 7421267.

llvm-svn: 89814

llvm-svn: 89275

the tail of a block may make that block a new candidate for duplication.

llvm-svn: 89264

llvm-svn: 89254

llvm-svn: 89225

contents of the block to be duplicated.  Use this for ARM Cortex A8/9 to
be more aggressive tail duplicating indirect branches, since it makes it
much more likely that they will be predicted in the branch target buffer.
Testcase coming soon.

llvm-svn: 89187

unnecessary.  It is broken because the "isIdenticalTo" check should be
negated.  If that is fixed, this code causes the CodeGen/X86/tail-opts.ll
test to fail, in the dont_merge_oddly function.  And, I confirmed that the
regression is real -- the generated code is worse.  As far as I can tell,
that tail-opts.ll test is checking for what this code is supposed to handle
and we're doing the right thing anyway.

llvm-svn: 89121

llvm-svn: 89114

folding optimizations.

llvm-svn: 89109

It was too difficult to keep the heuristics for merging and duplication
consistent.

llvm-svn: 89105

llvm-svn: 88940

llvm-svn: 88932

llvm-svn: 88929

llvm-svn: 88927

code-size win, and not when it's only likely to be code-size neutral,
such as when only a single instruction would be eliminated and a new
branch would be required.

This fixes rdar://7392894.

llvm-svn: 88692

llvm-svn: 86928

llvm-svn: 86926

can be made to fall through into the other.

llvm-svn: 86909

instead of typedefs for std::pair. This simplifies the type of
SameTails, which previously was std::vector<std::pair<std::vector<std::pair<unsigned, MachineBasicBlock *> >::iterator, MachineBasicBlock::iterator>

llvm-svn: 86885

llvm-svn: 86875

tail merging support to handle more cases.
 - Recognize several cases where tail merging is beneficial even when
   the tail size is smaller than the generic threshold.
 - Make use of MachineInstrDesc::isBarrier to help detect
   non-fallthrough blocks.
 - Check for and avoid disrupting fall-through edges in more cases.

llvm-svn: 86871

llvm-svn: 86856

llvm-svn: 86855

the numbers mean.

llvm-svn: 86854

llvm-svn: 86853

llvm-svn: 86642

llvm-svn: 86641

an unconditional branch (possibly from tail merging), this code is
trying to redirect all of its predecessors to go directly to the branch
target, but that isn't feasible for indirect branches.  The other
predecessors (that don't end with indirect branches) could theoretically
still be handled, but that is not easily done right now.

The AnalyzeBranch interface doesn't currently let us distinguish jump table
branches from indirect branches, and this code is currently handling
jump tables.  To avoid punting on address-taken blocks, we would have to give
up handling jump tables.  That seems like a bad tradeoff.

llvm-svn: 85975

llvm-svn: 85572

llvm-svn: 85519

common tail, except when the OptimizeForSize function attribute is present.
Radar 7338114.

llvm-svn: 85441

I'm going to redo this using the OptimizeForSize function attribute.

llvm-svn: 85426

use it to control tail merging when there is a tradeoff between performance
and code size.  When there is only 1 instruction in the common tail, we have
been merging.  That can be good for code size but is a definite loss for
performance.  Now we will avoid tail merging in that case when the
optimization level is "Aggressive", i.e., "-O3".  Radar 7338114.

Since the IfConversion pass invokes BranchFolding, it too needs to know
the optimization level.  Note that I removed the RegisterPass instantiation
for IfConversion because it required a default constructor.  If someone
wants to keep that for some reason, we can add a default constructor with
a hard-wired optimization level.

llvm-svn: 85346

to break up CFG diamonds by banishing one of the blocks to the end of
the function, which is bad for code density and branch size.

This does pessimize MultiSource/Benchmarks/Ptrdist/yacr2, the
benchmark cited as the reason for the change, however I've examined
the code and it looks more like a case of gaming a particular
branch than of being generally applicable.

llvm-svn: 84803

llvm-svn: 80994

llvm-svn: 80971