response from getModRefInfo is not useful here. Instead, check for identical
calls only in the NoModRef case.
Reapply r110270, and strengthen it to compensate for the memdep changes.
When both calls are readonly, there is no dependence between them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110382 91177308-0d34-0410-b5e6-96231b3b80d8
one is a suffix of the other, and FileCheck accepts superstrings.
Adjust the output to avoid this problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110280 91177308-0d34-0410-b5e6-96231b3b80d8
to return Ref if the left callsite only reads memory read or written
by the right callsite; fix BasicAliasAnalysis to implement this.
Add AliasAnalysisEvaluator support for testing the two-callsite
form of getModRefInfo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110270 91177308-0d34-0410-b5e6-96231b3b80d8
eliminate several const_casts.
Make CallSite implicitly convertible to ImmutableCallSite.
Rename the getModRefBehavior for intrinsic IDs to
getIntrinsicModRefBehavior to avoid overload ambiguity with CallSite,
which happens to be implicitly convertible to bool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110155 91177308-0d34-0410-b5e6-96231b3b80d8
of Value deletions and RAUWs, instead of relying on ScalarEvolution's
Scalars map being notified, as that's complicated at best, and
insufficient in general.
This means SCEVUnknown needs a non-trivial destructor, so introduce
a mechanism to allow ScalarEvolution to locate all the SCEVUnknowns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110086 91177308-0d34-0410-b5e6-96231b3b80d8
of my earlier data structure improvements until I can ensure that there are no iterator invalidation problems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109935 91177308-0d34-0410-b5e6-96231b3b80d8
extend it to handle the case where multiple RAUWs affect a single
SCEVUnknown.
Add a ScalarEvolution unittest to test for this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109705 91177308-0d34-0410-b5e6-96231b3b80d8
object, as it may still be referenced by SCEVs not cleaned up by the
use list traversal.
Also, in ScalarEvolution::forgetValue, only check for a SCEVUnknown
object for the original value, not for any value in the use list,
because other SCEVUnknown values aren't necessary obsolete at that
point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109570 91177308-0d34-0410-b5e6-96231b3b80d8
add instead a CallSite(Value* V) constructor that is consistent with ImmutableCallSize
and use that one in client code
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109553 91177308-0d34-0410-b5e6-96231b3b80d8
* contains(Loop), * getOutermostLoop()
* Improve getNameStr() to return a sensible name, if basic blocks are not named.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109490 91177308-0d34-0410-b5e6-96231b3b80d8
it inserted rather than using LoopInfo::getCanonicalInductionVariable to
rediscover it, since that doesn't work on non-canonical loops. This fixes
infinite recurrsion on such loops; PR7562.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109419 91177308-0d34-0410-b5e6-96231b3b80d8
The RegionInfo pass detects single entry single exit regions in a function,
where a region is defined as any subgraph that is connected to the remaining
graph at only two spots.
Furthermore an hierarchical region tree is built.
Use it by calling "opt -regions analyze" or "opt -view-regions".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109089 91177308-0d34-0410-b5e6-96231b3b80d8
Make MDNode::destroy private.
Fix the one thing that used MDNode::destroy, outside of MDNode itself.
One should never delete or destroy an MDNode explicitly. MDNodes
implicitly go away when there are no references to them (implementation
details aside).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109028 91177308-0d34-0410-b5e6-96231b3b80d8
would cause them to fail the way they are, but none of the other intervening patches seem likely either.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108818 91177308-0d34-0410-b5e6-96231b3b80d8
superclass (StaticPassInfo) and a constructor-ful subclass (PassInfo).", it is
breaking teh everything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108805 91177308-0d34-0410-b5e6-96231b3b80d8
it doesn't miss an opportunity to form a GEP, regardless of the
relative loop depths of the operands. This fixes rdar://8197217.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108475 91177308-0d34-0410-b5e6-96231b3b80d8
mutated by recursive simplification. This also enhances
ReplaceAndSimplifyAllUses to actually do a real RAUW
at the end of it, which updates any value handles
pointing to "From" to start pointing to "To". This
seems useful for debug info and random other VH users.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108415 91177308-0d34-0410-b5e6-96231b3b80d8
that was actually useful here.
Chris, please double check that this is the correct interpretation. I was
pretty sure, and ran it by Nick as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108129 91177308-0d34-0410-b5e6-96231b3b80d8
interface needs implementations to be consistent, so any code which
wants to support different semantics must use a different interface.
It's not currently worthwhile to add a new interface for this new
concept.
Document that AliasAnalysis doesn't support cross-function queries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107776 91177308-0d34-0410-b5e6-96231b3b80d8
entries associated with the value being erased in the
folding set map. These entries used to be harmless, because
a SCEVUnknown doesn't store any information about its Value*,
so having a new Value allocated at the old Value's address
wasn't a problem. But now that ScalarEvolution is storing more
information about values, this is no longer safe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107316 91177308-0d34-0410-b5e6-96231b3b80d8
on ScalarEvolution successfully folding and preserving
range information for both A-B and B-A. Now, if it gets
either one, it's sufficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107249 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107117 91177308-0d34-0410-b5e6-96231b3b80d8
properly handles instructions and arguments defined in different
functions, or across recursive function iterations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107109 91177308-0d34-0410-b5e6-96231b3b80d8
interprocedurally. Note that as of this writing, existing alias
analysis passes are not prepared to be used interprocedurally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107013 91177308-0d34-0410-b5e6-96231b3b80d8
assuming that loops are in canonical form, as ScalarEvolution doesn't
depend on LoopSimplify itself. Also, with indirectbr not all loops can
be simplified. This fixes PR7416.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106389 91177308-0d34-0410-b5e6-96231b3b80d8
scrounging through SCEVUnknown contents and SCEVNAryExpr operands;
instead just do a simple deterministic comparison of the precomputed
hash data.
Also, since this is more precise, it eliminates the need for the slow
N^2 duplicate detection code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105540 91177308-0d34-0410-b5e6-96231b3b80d8
encapsulation to force the users of these classes to know about the internal
data structure of the Operands structure. It also can lead to errors, like in
the MSIL writer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105539 91177308-0d34-0410-b5e6-96231b3b80d8
there could be multiple subexpressions within a single expansion which
require insert point adjustment. This fixes PR7306.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105510 91177308-0d34-0410-b5e6-96231b3b80d8
on RAUW of functions, this is a correctness issue instead of a mere memory
usage problem.
No testcase until the new MergeFunctions can land.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103653 91177308-0d34-0410-b5e6-96231b3b80d8
Also, pass true for isSigned even when creating constants for unsigned
comparisons, because the point is to create an all-ones constant,
rather than UINT64_MAX, even for integers wider than 64 bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102946 91177308-0d34-0410-b5e6-96231b3b80d8
SimplifyICmpOperands will simplify such cases to EQ or NE. This makes
the correcntess of the code independent on SimplifyICmpOperands doing
certain simplifications.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102927 91177308-0d34-0410-b5e6-96231b3b80d8
if an indirect call site was removed and a direct one was added, not
just if an indirect call site was modified to be direct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102830 91177308-0d34-0410-b5e6-96231b3b80d8
that can have a big effect :). The first is to enable the
iterative SCC passmanager juice that kicks in when the
scc passmgr detects that a function pass has devirtualized
a call. In this case, it will rerun all the passes it
manages on the SCC, up to the iteration count limit (4). This
is useful because a function pass may devirualize a call, and
we want the inliner to inline it, or pruneeh to infer stuff
about it, etc.
The second patch is to add *all* call sites to the
DevirtualizedCalls list the inliner uses. This list is
about to get renamed, but the jist of this is that the
inliner now reconsiders *all* inlined call sites as candidates
for further inlining. The intuition is this that in cases
like this:
f() { g(1); } g(int x) { h(x); }
We analyze this bottom up, and may decide that it isn't
profitable to inline H into G. Next step, we decide that it is
profitable to inline G into F, and do so, which means that F
now calls H. Even though the call from G -> H may not have been
profitable to inline, the call from F -> H may be (in this case
because a constant allows folding etc).
In my spot checks, this doesn't have a big impact on code. For
example, the LLC output for 252.eon grew from 0.02% (from
317252 to 317308) and 176.gcc actually shrunk by .3% (from 1525612
to 1520964 bytes). 252.eon never iterated in the SCC Passmgr,
176.gcc iterated at most 1 time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102823 91177308-0d34-0410-b5e6-96231b3b80d8
were still inlining self-recursive functions into other functions.
Inlining a recursive function into itself has the potential to
reduce recursion depth by a factor of 2, inlining a recursive
function into something else reduces recursion depth by exactly
1. Since inlining a recursive function into something else is a
weird form of loop peeling, turn this off.
The deleted testcase was added by Dale in r62107, since then
we're leaning towards not inlining recursive stuff ever. In any
case, if we like inlining recursive stuff, it should be done
within the recursive function itself to get the algorithm
recursion depth win.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102798 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't dominate the header is needed, don't check whether the increment
expression has computable loop evolution. While the operands of an
addrec are required to be loop-invariant, they're not required to
dominate any part of the loop. This fixes PR6914.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102389 91177308-0d34-0410-b5e6-96231b3b80d8
Also, generalize ScalarEvolutions's min and max recognition to handle
some new forms of min and max that this change makes more common.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102234 91177308-0d34-0410-b5e6-96231b3b80d8
refactored out of ScalarEvolution::isImpliedCond, which will be updated
to use this new utility routine soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102229 91177308-0d34-0410-b5e6-96231b3b80d8
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'
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102194 91177308-0d34-0410-b5e6-96231b3b80d8
misses an opportunity to fold add operands, but folds them
after LSR has separated them out. This fixes rdar://7886751.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102157 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102120 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101973 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101969 91177308-0d34-0410-b5e6-96231b3b80d8
just ask ScalarEvolution for it on demand. This helps IVUsers be more robust
in the case of expressions changing underneath it. This fixes PR6862.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101819 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101658 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101628 91177308-0d34-0410-b5e6-96231b3b80d8
Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101579 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101565 91177308-0d34-0410-b5e6-96231b3b80d8
to CallGraphSCCPass's instead of passing around a
std::vector<CallGraphNode*>. No functionality change,
but now we have a much tidier interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101558 91177308-0d34-0410-b5e6-96231b3b80d8
dependent analyses, and increase code size, so doing it profitably would
require more complex heuristics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101471 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101465 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101397 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101364 91177308-0d34-0410-b5e6-96231b3b80d8