| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
|  | 
asm construct into an assertion failure.
llvm-svn: 71757
 | 
| | 
| 
| 
| 
| 
|  | 
Radar 6867696
llvm-svn: 71750
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Basically, there was a situation where it was getting an empty vector and doing
a .back() on that. Which isn't cool.
llvm-svn: 71746
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
of exception handling builtin sjlj targets in functions turns out not to 
be necessary. Marking the intrinsic implementation in the .td file as 
defining all registers is sufficient to get the context saved properly by 
the containing function.
llvm-svn: 71743
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
|  | 
llvm-svn: 71740
 | 
| | 
| 
| 
| 
| 
|  | 
field name.  No functional changes.
llvm-svn: 71739
 | 
| | 
| 
| 
|  | 
llvm-svn: 71738
 | 
| | 
| 
| 
| 
| 
|  | 
few places
llvm-svn: 71735
 | 
| | 
| 
| 
|  | 
llvm-svn: 71726
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
booleans. This gives a better indication of what the "addReg()" is
doing. Remembering what all of those booleans mean isn't easy, especially if you
aren't spending all of your time in that code.
I took Jakob's suggestion and made it illegal to pass in "true" for the
flag. This should hopefully prevent any unintended misuse of this (by reverting
to the old way of using addReg()).
llvm-svn: 71722
 | 
| | 
| 
| 
|  | 
llvm-svn: 71717
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
belonged. The variable declaration stuff wasn't happy with it where it
was. Sorry that the testcase is so big. Bugpoint wasn't able to reduce it
successfully.
llvm-svn: 71714
 | 
| | 
| 
| 
| 
| 
| 
|  | 
external.  These may have address 0 and are not safe
to execute unconditionally.
llvm-svn: 71688
 | 
| | 
| 
| 
|  | 
llvm-svn: 71678
 | 
| | 
| 
| 
| 
| 
| 
|  | 
is not known to be nothrow.  This allows readnone/readonly functions
to be deleted even if we don't know whether the callee can throw.
llvm-svn: 71676
 | 
| | 
| 
| 
| 
| 
|  | 
includeing declarations. Later emit them from their section lists.
llvm-svn: 71661
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
IVUsers.cpp: In member function ‘bool llvm::IVUsers::AddUsersIfInteresting(llvm::Instruction*)’:
 IVUsers.cpp:221: warning: ‘isSigned’ may be used uninitialized in this function
with gcc-4.3.
llvm-svn: 71654
 | 
| | 
| 
| 
|  | 
llvm-svn: 71646
 | 
| | 
| 
| 
|  | 
llvm-svn: 71645
 | 
| | 
| 
| 
|  | 
llvm-svn: 71644
 | 
| | 
| 
| 
| 
| 
|  | 
operand was killed, the kill needs to be removed from regB's VarInfo.
llvm-svn: 71635
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
getNoopOrSignExtend, and getTruncateOrNoop. These are similar
to getTruncateOrZeroExtend etc., except that they assert that
the conversion is either not widening or narrowing, as
appropriate. These will be used in some upcoming fixes.
llvm-svn: 71632
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
without one.  Use it where we were using abs on
int64_t objects.
(I strongly suspect the casts to unsigned in the
fragments in LoopStrengthReduce are not doing whatever
the original intent was, but the obvious change to
uint64_t doesn't work.  Maybe later.)
llvm-svn: 71612
 | 
| | 
| 
| 
| 
| 
| 
|  | 
a supporting preliminary patch for GCC-compatible SjLJ exception handling. Note that these intrinsics are not designed to be invoked directly by the user, but
rather used by the front-end as target hooks for exception handling.
llvm-svn: 71610
 | 
| | 
| 
| 
| 
| 
|  | 
don't want to add nops in the outer loop for the sake of aligning the inner loop.
llvm-svn: 71609
 | 
| | 
| 
| 
| 
| 
|  | 
produce side effects.
llvm-svn: 71606
 | 
| | 
| 
| 
|  | 
llvm-svn: 71602
 | 
| | 
| 
| 
|  | 
llvm-svn: 71601
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
- moved shrink wrapping code from PrologEpilogInserter.cpp to
  new file ShrinkWrapping.cpp.
- moved PEI pass definition into new shared header PEI.h.
llvm-svn: 71588
 | 
| | 
| 
| 
|  | 
llvm-svn: 71587
 | 
| | 
| 
| 
|  | 
llvm-svn: 71582
 | 
| | 
| 
| 
| 
| 
|  | 
when doing forward / backward propagation.
llvm-svn: 71574
 | 
| | 
| 
| 
|  | 
llvm-svn: 71563
 | 
| | 
| 
| 
|  | 
llvm-svn: 71562
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Later in asmprinter, go over thsese sections and print them.
Do not print empty sections.
llvm-svn: 71560
 | 
| | 
| 
| 
| 
| 
|  | 
just emit a comment for readability.
llvm-svn: 71544
 | 
| | 
| 
| 
| 
| 
|  | 
to check if an insn is accessing memory during mem sel optimization.
llvm-svn: 71537
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
after finding the (unique) layout predecessor.  Sometimes a block may be listed
more than once, and processing it more than once in this loop can lead to
inconsistent values for FtTBB/FtFBB, since the AnalyzeBranch method does not
clear these values.  There's no point in continuing the loop regardless.
The testcase for this is reduced from the 2003-05-02-DependentPHI SingleSource
test.
llvm-svn: 71536
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
and generalize it so that it can be used by IndVarSimplify. Implement the
base IndVarSimplify transformation code using IVUsers. This removes
TestOrigIVForWrap and associated code, as ScalarEvolution now has enough
builtin overflow detection and folding logic to handle all the same cases,
and more. Run "opt -iv-users -analyze -disable-output" on your favorite
loop for an example of what IVUsers does.
This lets IndVarSimplify eliminate IV casts and compute trip counts in
more cases. Also, this happens to finally fix the remaining testcases
in PR1301.
Now that IndVarSimplify is being more aggressive, it occasionally runs
into the problem where ScalarEvolutionExpander's code for avoiding
duplicate expansions makes it difficult to ensure that all expanded
instructions dominate all the instructions that will use them. As a
temporary measure, IndVarSimplify now uses a FixUsesBeforeDefs function
to fix up instructions inserted by SCEVExpander. Fortunately, this code
is contained, and can be easily removed once a more comprehensive
solution is available.
llvm-svn: 71535
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
These values aren't analyzable, so they don't care if more information
about the loop trip count can be had. Also, SCEVUnknown is used for
a PHI while the PHI itself is being analyzed, so it needs to be left
in the Scalars map. This fixes a variety of subtle issues.
llvm-svn: 71533
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
return the correct value when the cast operand is all zeros. This ought
to be pretty rare, because it would mean that the regular SCEV folding
routines missed a case, though there are cases they might legitimately
miss. Also, it's unlikely anything currently using GetMinTrailingZeros
cares about this case.
llvm-svn: 71532
 | 
| | 
| 
| 
|  | 
llvm-svn: 71520
 | 
| | 
| 
| 
| 
| 
| 
|  | 
blast it away.
- Move InlineInfo bookkeeping to bookkeep the correct debug info object.
llvm-svn: 71519
 | 
| | 
| 
| 
|  | 
llvm-svn: 71495
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
postinc iv value. Previously LSR would only optimize those which are in the loop latch block. However, if LSR can prove it is safe (and profitable), it's now possible to change those not in the latch blocks to use postinc values.
Also, if the compare is the only use, LSR would place the iv increment instruction before the compare instead in the latch.
llvm-svn: 71485
 | 
| | 
| 
| 
| 
| 
|  | 
sucessor info.
llvm-svn: 71478
 | 
| | 
| 
| 
|  | 
llvm-svn: 71472
 |