| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 102232
|
| |
|
|
|
|
|
| |
refactored out of ScalarEvolution::isImpliedCond, which will be updated
to use this new utility routine soon.
llvm-svn: 102229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the instruction pointer value for debuggability.
We now get dump output that looks like this:
Call graph node for function: 'f1'<<0x1017086b0>> #uses=1
CS<0x1017046f8> calls external node
Call graph node for function: '_ZNSt6vectorIdSaIdEEC1EmRKdRKS0_'<<0x1017086f0>> #uses=1
CS<0x0> calls external node
Call graph node for function: 'f4'<<0x1017087a0>> #uses=1
CS<0x101708c88> calls function 'f3'
llvm-svn: 102194
|
| |
|
|
|
|
|
| |
misses an opportunity to fold add operands, but folds them
after LSR has separated them out. This fixes rdar://7886751.
llvm-svn: 102157
|
| |
|
|
|
|
| |
use ScalarEvolutions "any" extend function.
llvm-svn: 102156
|
| |
|
|
|
|
|
|
|
| |
Fix RefreshCallGraph to use CGN->replaceCallEdge instead of hand
rolling its own loop. replaceCallEdge properly maintains the
reference counts of the nodes, fixing a crash exposed by the
iterative callgraph stuff.
llvm-svn: 102120
|
| |
|
|
|
|
| |
assertion failures in extreme cases.
llvm-svn: 102042
|
| |
|
|
| |
llvm-svn: 102041
|
| |
|
|
|
|
| |
with ScalarEvolution's overall approach to pointer types.
llvm-svn: 102003
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we have RefreshCallGraph detect when a function pass devirtualizes
a call, and have CGSCCPassMgr iterate (up to a count) when this
happens. This allows (in the example) GVN to devirtualize the
call in foo, then the inliner to inline it away.
This is not currently enabled because I haven't done any analysis
on the (potentially substantial) code size or performance impact of
doing this, and guess what, it exposes callgraph updating bugs in
various passes. This is progress though, and you can play with it
by passing -max-cg-scc-iterations=5 to opt.
llvm-svn: 101973
|
| |
|
|
|
|
|
|
|
| |
recursive callsites, inlining can reduce the number of calls by
exponential factors, as it does in
MultiSource/Benchmarks/Olden/treeadd. More involved heuristics
will be needed.
llvm-svn: 101969
|
| |
|
|
| |
llvm-svn: 101897
|
| |
|
|
|
|
| |
inst simplify. No functionality change.
llvm-svn: 101873
|
| |
|
|
|
|
| |
references to it.
llvm-svn: 101847
|
| |
|
|
|
|
|
| |
just ask ScalarEvolution for it on demand. This helps IVUsers be more robust
in the case of expressions changing underneath it. This fixes PR6862.
llvm-svn: 101819
|
| |
|
|
|
|
|
|
|
|
|
|
| |
by switching CachedFunctionInfo from a std::map to a
ValueMap (which is implemented in terms of a DenseMap).
DenseMap has different iterator invalidation semantics
than std::map.
This should hopefully fix the dragonegg builder.
llvm-svn: 101658
|
| |
|
|
| |
llvm-svn: 101657
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|