The LowerSubregs pass needs to preserve implicit def operands attached to
EXTRACT_SUBREG instructions when it replaces those instructions with copies.

llvm-svn: 107189

llvm-svn: 107141

of getPhysicalRegisterRegClass with it.

If we want to make a copy (or estimate its cost), it is better to use the
smallest class as more efficient operations might be possible.

llvm-svn: 107140

to unsigned only to extend back to a pointer sized value on the
next line.

llvm-svn: 107139

llvm-svn: 107132

llvm-svn: 107127

back-edges), make sure not to include dbg_value instructions in the count.
Closing in on the end of rdar://7797940

llvm-svn: 107119

There are 2 changes relative to the previous version of the patch:

1) For the "simple" if-conversion case, there's no need to worry about
RemoveExtraEdges not handling an unanalyzable branch.  Predicated terminators
are ignored in this context, so RemoveExtraEdges does the right thing.
This might break someday if we ever treat indirect branches (BRIND) as
predicable, but for now, I just removed this part of the patch, because
in the case where we do not add an unconditional branch, we rely on keeping
the fall-through edge to CvtBBI (which is empty after this transformation).

The change relative to the previous patch is:

@@ -1036,10 +1036,6 @@
     IterIfcvt = false;
   }
 
-  // RemoveExtraEdges won't work if the block has an unanalyzable branch,
-  // which is typically the case for IfConvertSimple, so explicitly remove
-  // CvtBBI as a successor.
-  BBI.BB->removeSuccessor(CvtBBI->BB);
   RemoveExtraEdges(BBI);
 
   // Update block info. BB can be iteratively if-converted.


2) My patch exposed a bug in the code for merging the tail of a "diamond",
which had previously never been exercised.  The code was simply checking that
the tail had a single predecessor, but there was a case in
MultiSource/Benchmarks/VersaBench/dbms where that single predecessor was
neither edge of the diamond.  I added the following change to check for
that:

@@ -1276,7 +1276,18 @@
   // tail, add a unconditional branch to it.
   if (TailBB) {
     BBInfo TailBBI = BBAnalysis[TailBB->getNumber()];
-    if (TailBB->pred_size() == 1 && !TailBBI.HasFallThrough) {
+    bool CanMergeTail = !TailBBI.HasFallThrough;
+    // There may still be a fall-through edge from BBI1 or BBI2 to TailBB;
+    // check if there are any other predecessors besides those.
+    unsigned NumPreds = TailBB->pred_size();
+    if (NumPreds > 1)
+      CanMergeTail = false;
+    else if (NumPreds == 1 && CanMergeTail) {
+      MachineBasicBlock::pred_iterator PI = TailBB->pred_begin();
+      if (*PI != BBI1->BB && *PI != BBI2->BB)
+        CanMergeTail = false;
+    }
+    if (CanMergeTail) {
       MergeBlocks(BBI, TailBBI);
       TailBBI.IsDone = true;
     } else {

With these fixes, I was able to run all the SingleSource and MultiSource
tests successfully.

llvm-svn: 107110

can't be changed arbitrarily by the DAGCombiner without checking if it is
running after legalization.

llvm-svn: 107097

llvm-svn: 107085

have to be registers, per gcc documentation.  This affects
the logic for determining what "g" should lower to.  PR 7393.
A couple of existing testcases are affected.

llvm-svn: 107079

llvm-svn: 107065

llvm-svn: 107060

you would expect.

Don't assert on that case, just give up.

This fixes PR7513.

llvm-svn: 107046

When an instruction has tied operands and physreg defines, we must take extra
care that the tied operands conflict with neither physreg defs nor uses.

The special treatment is given to inline asm and instructions with tied operands
/ early clobbers and physreg defines.

This fixes PR7509.

llvm-svn: 107043

Radar 8122864.

llvm-svn: 107027

llvm-svn: 107014

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

llvm-svn: 107009

llvm-svn: 106990

This produces terrible but correct code.

llvm-svn: 106952

regressions.

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

llvm-svn: 106951

llvm-svn: 106943

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

The VNInfo.kills vector was almost unused except for all the code keeping it
updated. The few places using it were easily rewritten to check for interval
ends instead.

The two new methods LiveInterval::killedAt and killedInRange are replacements.

This brings us down to 3 independent data structures tracking kills.

llvm-svn: 106905

llvm-svn: 106901

llvm-svn: 106895

llvm-svn: 106894

for an "i" constraint should get lowered; PR 6309.  While
this argument was passed around a lot, this is the only
place it was used, so it goes away from a lot of other
places.

llvm-svn: 106893

- 2010-06-25-CoalescerSubRegDefDead.ll is the testcase for r106878.

llvm-svn: 106880

are dead, not just the def of this register. I.e., a register could be dead, but
it's subreg isn't.

Testcase to follow with a subsequent patch.

llvm-svn: 106878

llvm-svn: 106865

is not used.  Spotted by gcc-4.6.

llvm-svn: 106854

and CallInst for getting hold
of the intrinsic's arguments

simplify along the way (at least for me this is much more legible now)
Bill, Baldrick or Anton, please review\!

llvm-svn: 106838

llvm-svn: 106837

llvm-svn: 106836

llvm-svn: 106835

llvm-svn: 106833

llvm-svn: 106829

llvm-svn: 106828