| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 100515
|