| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
is stripped off. Currently set unconditionally, since the API
does not provide a way of working out if anything was actually
stripped off.
llvm-svn: 107142
|
|
|
|
| |
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
|
|
|
|
|
|
| |
ignored! Remove it.
llvm-svn: 107138
|
|
|
|
|
|
| |
but then not actually used - maybe a bug? Remove the variable.
llvm-svn: 107137
|
|
|
|
| |
llvm-svn: 107136
|
|
|
|
| |
llvm-svn: 107135
|
|
|
|
|
|
| |
and thumb_mode.
llvm-svn: 107133
|
|
|
|
| |
llvm-svn: 107132
|
|
|
|
| |
llvm-svn: 107131
|
|
|
|
| |
llvm-svn: 107130
|
|
|
|
|
|
|
|
|
| |
in terms of Op<> and ArgOffset. This works for
values of {0, 1} for ArgOffset.
Please note that ArgOffset will become 0 soon and
will go away eventually.
llvm-svn: 107129
|
|
|
|
| |
llvm-svn: 107128
|
|
|
|
| |
llvm-svn: 107127
|
|
|
|
|
|
| |
XDEBUG is enabled.
llvm-svn: 107125
|
|
|
|
|
|
| |
be called.
llvm-svn: 107124
|
|
|
|
| |
llvm-svn: 107122
|
|
|
|
| |
llvm-svn: 107121
|
|
|
|
|
|
|
| |
back-edges), make sure not to include dbg_value instructions in the count.
Closing in on the end of rdar://7797940
llvm-svn: 107119
|
|
|
|
|
|
|
|
| |
instruction to an add scev, it's not safe to blindly transfer the
inbounds flag from a gep instruction to an nsw on the scev for the
gep.
llvm-svn: 107117
|
|
|
|
| |
llvm-svn: 107116
|
|
|
|
| |
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
|