llvm-svn: 107060

block, not...", it caused a bunch of nightly test regressions.

llvm-svn: 107009

regressions.

--- Reverse-merging r106939 into '.':
U    test/CodeGen/Thumb2/thumb2-ifcvt3.ll
U    lib/CodeGen/IfConversion.cpp

llvm-svn: 106951

if-conversion.  The RemoveExtraEdges function doesn't work for blocks that
end with unanalyzable branches, so in those cases, the "extra" edges must
be explicitly removed.  The CopyAndPredicateBlock and MergeBlocks methods
can also avoid copying successor edges due to branches that have already
been removed.  The latter case is especially helpful when MergeBlocks is
called for handling "diamond" if-conversions, where otherwise you can end
up with some weird intermediate states in the CFG.  Unfortunately I've
been unable to find cases where this cleanup actually makes a significant
difference in the code.  There is one test where we manage to remove an
empty block at the end of a function.  Radar 6911268.

llvm-svn: 106939

just at the head, when doing diamond if-conversion. rdar://7797940

llvm-svn: 106907

llvm-svn: 106901

llvm-svn: 106894

llvm-svn: 106542

llvm-svn: 106383

- 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

llvm-svn: 106330

Teach iff-converter to properly count # of dups. It was not skipping over dbg_value's which resulted in non-duplicated instructions being deleted. rdar://8104384.

llvm-svn: 106323

so when IfConverter::CopyAndPredicateBlock checks to see if it should ignore
an instruction because it is a branch, it should not check if the branch is
predicated.

This case (when IgnoreBr is true) is only relevant from IfConvertTriangle,
where new branches are inserted after the block has been copied and predicated.
If the original branch is not removed, we end up with multiple conditional
branches (possibly conflicting) at the end of the block.  Aside from any
immediate errors resulting from that, this confuses the AnalyzeBranch functions
so that the branches are not analyzable.  That in turn causes the IfConverter to
think that the "Simple" pattern can be applied, and things go downhill fast
because the "Simple" pattern does _not_ apply if the block can fall through.

This is pretty fragile.  If there are other degenerate cases where AnalyzeBranch
fails, but where the block may still fall through, the IfConverter should not
perform its "Simple" if-conversion.  But, I don't know how to do that with the
current AnalyzeBranch interface, so for now, the best thing seems to be to
avoid creating branches that AnalyzeBranch cannot handle.

Evan, please review!

llvm-svn: 106291

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

Make post-ra scheduling, anti-dep breaking, and register scavenger (conservatively) aware of predicated instructions. This enables ARM to move if-conversion before post-ra scheduler.

llvm-svn: 106091

llvm-svn: 106057

llvm-svn: 106027

llvm-svn: 106015

Make sure to skip the dbg_value instructions when moving dups out of the
diamond. rdar://7797940

llvm-svn: 105965

llvm-svn: 105554

llvm-svn: 105541

llvm-svn: 105498

Change errs() to dbgs().

llvm-svn: 92520

Allow target to disable if-converting predicable instructions. e.g. NEON instructions under ARM mode.

llvm-svn: 89541

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

Chris claims we should never have visibility_hidden inside any .cpp file but
that's still not true even after this commit.

llvm-svn: 85042

llvm-svn: 80994

MachineInstr and MachineOperand.  This required eliminating a
bunch of stuff that was using DOUT, I hope that bill doesn't
mind me stealing his fun. ;-)

llvm-svn: 79813

llvm-svn: 79751

 - Some clients which used DOUT have moved to DEBUG. We are deprecating the
   "magic" DOUT behavior which avoided calling printing functions when the
   statement was disabled. In addition to being unnecessary magic, it had the
   downside of leaving code in -Asserts builds, and of hiding potentially
   unnecessary computations.

llvm-svn: 77019

This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").

llvm-svn: 75640

llvm-svn: 75423

and abort()/exit() -> llvm_report_error().

llvm-svn: 75363

llvm-svn: 74140

llvm-svn: 73423

assertion is failing for some tests.

llvm-svn: 71779

block with its unique predecessor.  Change the code to assert if that is not
the case, instead of trying to handle situations where the block has
multiple predecessors.

llvm-svn: 71744

Dan was trying to catch the case where a basic block ends with a conditional
branch to the fall-through block.  In this case, all the instructions have
been moved out of FromBBI, leaving it empty.  It cannot end with a
conditional branch.  As the existing comment indicates, it will always fall
through to the next block.  If the block already had the next block (NBB)
listed as a successor, the preceding loop has a check for that and does not
remove it.  Thus, we need to check and add the successor only when it is
not already listed.

With Dan's change, the empty block often ends up with the fall-through
successor listed twice.  This exposed the problem in pr4195, where
CodePlacementOpt did not handle the same predecessor listed more than once.
It is also at least partially responsible for pr4202 and probably a similar
issue with Thumb branches being out of range.

llvm-svn: 71742

llvm-svn: 71741