| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
CGSCC can delete nodes in regions of the callgraph that
have already been visited. If new CG nodes are allocated
to the same pointer, we shouldn't abort, just handle it
correctly by assigning a new number. This should restore
stability by removing invalidated pointers that *will* be
reused from the densemap in the iterator.
llvm-svn: 101628
|
| |
|
|
| |
llvm-svn: 101583
|
| |
|
|
|
|
|
| |
Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.
llvm-svn: 101579
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to keep the node entries in scc_iterator up to date instead of dangling as
the SCC mutates.
This is a really terrible problem which was causing -g to affect codegen
because it would permute the memory image of the compiler process.
Thanks to Dale for expertly hunting it down.
llvm-svn: 101565
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 101562
|
| |
|
|
|
|
|
|
| |
to CallGraphSCCPass's instead of passing around a
std::vector<CallGraphNode*>. No functionality change,
but now we have a much tidier interface.
llvm-svn: 101558
|
| |
|
|
| |
llvm-svn: 101543
|
| |
|
|
|
|
|
| |
dependent analyses, and increase code size, so doing it profitably would
require more complex heuristics.
llvm-svn: 101471
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
with a fix for self-hosting
rotate CallInst operands, i.e. move callee to the back
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101465
|
| |
|
|
| |
llvm-svn: 101463
|
| |
|
|
|
|
|
| |
expression canonicalization. Its job is to print what's there, not to
make judgements about it.
llvm-svn: 101461
|
| |
|
|
| |
llvm-svn: 101434
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
with a fix
rotate CallInst operands, i.e. move callee to the back
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101397
|
| |
|
|
| |
llvm-svn: 101376
|
| |
|
|
|
|
| |
in addition to the predecessor.
llvm-svn: 101374
|
| |
|
|
| |
llvm-svn: 101368
|
| |
|
|
|
|
|
|
|
|
| |
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101364
|
| |
|
|
| |
llvm-svn: 101298
|
| |
|
|
| |
llvm-svn: 101265
|
| |
|
|
| |
llvm-svn: 101248
|
| |
|
|
|
|
| |
that one operand is always greater than another.
llvm-svn: 101142
|
| |
|
|
| |
llvm-svn: 101141
|
| |
|
|
| |
llvm-svn: 101086
|
| |
|
|
|
|
|
| |
they're used a lot by getNodeForGEP, which can be called a lot.
This speeds up -iv-users by around 15% on several testcases.
llvm-svn: 101083
|
| |
|
|
|
|
|
|
| |
The information is already available with "opt -analyze". The DominatorTree
does also not have this in its runOnFunction. So they behave now
more consistent.
llvm-svn: 101038
|
| |
|
|
|
|
|
| |
This template is not needed anymore as it was replaced by the
DOTGraphTraitsViewer.
llvm-svn: 101036
|
| |
|
|
|
|
|
| |
have preheaders or dedicated exit blocks, as clients may not otherwise
need to run LoopSimplify.
llvm-svn: 101030
|
| |
|
|
|
|
|
|
|
| |
AddRecs so that it checks for overflow in the computation that it is
performing, rather than just checking hasNo{Signed,Unsigned}Wrap, since
those flags are for a different computation. This fixes a bug that
impacts an upcoming change.
llvm-svn: 101028
|
| |
|
|
| |
llvm-svn: 101009
|
| |
|
|
| |
llvm-svn: 101001
|
| |
|
|
|
|
| |
loop conditions which are invariants.
llvm-svn: 100995
|
| |
|
|
| |
llvm-svn: 100994
|
| |
|
|
|
|
| |
ConstantRange(0, 0) creates an empty range rather than a full one.
llvm-svn: 100993
|
| |
|
|
|
|
| |
intentionally ignored.
llvm-svn: 100984
|
| |
|
|
| |
llvm-svn: 100983
|
| |
|
|
| |
llvm-svn: 100981
|
| |
|
|
|
|
|
| |
that it's only testing for the entry condition, not full loop-invariant
conditions.
llvm-svn: 100979
|
| |
|
|
|
|
|
| |
a hoisted intermediate result if the intermediate result isn't an
Instruction.
llvm-svn: 100884
|
| |
|
|
| |
llvm-svn: 100874
|
| |
|
|
| |
llvm-svn: 100841
|
| |
|
|
|
|
| |
be sent to LSR, which it isn't prepared to handle.
llvm-svn: 100839
|
| |
|
|
| |
llvm-svn: 100825
|
| |
|
|
| |
llvm-svn: 100824
|
| |
|
|
| |
llvm-svn: 100802
|
| |
|
|
|
|
| |
unintended behavior.
llvm-svn: 100798
|
| |
|
|
| |
llvm-svn: 100789
|
| |
|
|
| |
llvm-svn: 100780
|
| |
|
|
|
|
|
| |
undef as 0, since it can't force other analyses to intepret the undef
in the same way.
llvm-svn: 100749
|
| |
|
|
| |
llvm-svn: 100713
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicitly split into stride-and-offset pairs. Also, add the
ability to track multiple post-increment loops on the same expression.
This refines the concept of "normalizing" SCEV expressions used for
to post-increment uses, and introduces a dedicated utility routine for
normalizing and denormalizing expressions.
This fixes the expansion of expressions which are post-increment users
of more than one loop at a time. More broadly, this takes LSR another
step closer to being able to reason about more than one loop at a time.
llvm-svn: 100699
|