| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 107114
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
properly handles instructions and arguments defined in different
functions, or across recursive function iterations.
llvm-svn: 107109
|
| |
|
|
| |
llvm-svn: 107108
|
| |
|
|
|
|
| |
the same as ARM except that the condition code field is always set to ARMCC::AL.
llvm-svn: 107107
|
| |
|
|
|
|
|
| |
can't be changed arbitrarily by the DAGCombiner without checking if it is
running after legalization.
llvm-svn: 107097
|
| |
|
|
|
|
| |
of the Subtarget.
llvm-svn: 107086
|
| |
|
|
| |
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: 107077
|
| |
|
|
| |
llvm-svn: 107074
|
| |
|
|
| |
llvm-svn: 107073
|
| |
|
|
|
|
|
| |
code in unreachable blocks, which have have use-def cycles.
This fixes PR7514.
llvm-svn: 107071
|
| |
|
|
| |
llvm-svn: 107070
|
| |
|
|
| |
llvm-svn: 107068
|
| |
|
|
| |
llvm-svn: 107067
|
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 107042
|
| |
|
|
|
|
| |
Remove library check and regenerate configure.
llvm-svn: 107028
|
| |
|
|
|
|
| |
Radar 8122864.
llvm-svn: 107027
|
| |
|
|
| |
llvm-svn: 107017
|
| |
|
|
| |
llvm-svn: 107016
|
| |
|
|
| |
llvm-svn: 107015
|
| |
|
|
| |
llvm-svn: 107014
|
| |
|
|
|
|
|
| |
interprocedurally. Note that as of this writing, existing alias
analysis passes are not prepared to be used interprocedurally.
llvm-svn: 107013
|
| |
|
|
|
|
| |
block, not...", it caused a bunch of nightly test regressions.
llvm-svn: 107009
|
| |
|
|
| |
llvm-svn: 107004
|
| |
|
|
| |
llvm-svn: 107003
|
| |
|
|
| |
llvm-svn: 107002
|
| |
|
|
| |
llvm-svn: 107000
|
| |
|
|
| |
llvm-svn: 106990
|
| |
|
|
|
|
| |
to emit local variable's debug info of deleted functions.
llvm-svn: 106989
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 106988
|
| |
|
|
|
|
| |
MDNode from subprogram declare MDNode.
llvm-svn: 106985
|
| |
|
|
|
|
|
|
| |
large integers, the first inserted value would always create
an 'or X, 0'. Even though this is trivially zapped by
instcombine, don't bother creating this pointless instruction.
llvm-svn: 106979
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
the returned value after the tail call if it differs from other return
values. The optimal thing to do would be to introduce a phi node for
the return value, but for the moment just fix the miscompile.
llvm-svn: 106947
|
| |
|
|
| |
llvm-svn: 106946
|
| |
|
|
| |
llvm-svn: 106945
|
| |
|
|
| |
llvm-svn: 106944
|
| |
|
|
| |
llvm-svn: 106943
|
| |
|
|
| |
llvm-svn: 106942
|
| |
|
|
| |
llvm-svn: 106940
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 106938
|
| |
|
|
| |
llvm-svn: 106935
|