| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 104970
|
|
|
|
| |
llvm-svn: 104957
|
|
|
|
| |
llvm-svn: 104953
|
|
|
|
|
|
| |
reference the stack.
llvm-svn: 104951
|
|
|
|
|
|
|
| |
effective no-op constructs, to make it more effective on
unoptimized IR.
llvm-svn: 104950
|
|
|
|
|
|
|
| |
lib/Transforms/Utils and into lib/Analysis so that Analysis passes
can use them.
llvm-svn: 104949
|
|
|
|
| |
llvm-svn: 104948
|
|
|
|
| |
llvm-svn: 104936
|
|
|
|
| |
llvm-svn: 104841
|
|
|
|
|
|
|
| |
PR7026
Patch by Pekka Jääskeläinen!
llvm-svn: 104780
|
|
|
|
|
|
|
| |
option from lintModule, which was an artifact from being
based on Verifier code.
llvm-svn: 104765
|
|
|
|
|
|
| |
and Write, and add a comment explaining this.
llvm-svn: 104756
|
|
|
|
| |
llvm-svn: 104752
|
|
|
|
| |
llvm-svn: 104748
|
|
|
|
| |
llvm-svn: 104744
|
|
|
|
| |
llvm-svn: 104274
|
|
|
|
|
|
| |
optimizer.
llvm-svn: 103798
|
|
|
|
|
|
|
|
|
|
| |
on RAUW of functions, this is a correctness issue instead of a mere memory
usage problem.
No testcase until the new MergeFunctions can land.
llvm-svn: 103653
|
|
|
|
| |
llvm-svn: 103422
|
|
|
|
| |
llvm-svn: 103325
|
|
|
|
| |
llvm-svn: 103318
|
|
|
|
| |
llvm-svn: 103305
|
|
|
|
| |
llvm-svn: 103300
|
|
|
|
| |
llvm-svn: 103295
|
|
|
|
| |
llvm-svn: 103276
|
|
|
|
| |
llvm-svn: 103272
|
|
|
|
| |
llvm-svn: 103264
|
|
|
|
|
|
| |
DebugInfoFinder and iterates over all the contents calling print.
llvm-svn: 103262
|
|
|
|
| |
llvm-svn: 103261
|
|
|
|
|
|
| |
methods, and add dump functions implemented in terms of the print.
llvm-svn: 103254
|
|
|
|
|
|
| |
of doing the same thing manually.
llvm-svn: 102997
|
|
|
|
| |
llvm-svn: 102996
|
|
|
|
|
|
| |
debug info used by a module.
llvm-svn: 102995
|
|
|
|
|
|
| |
same, now that getConstant has overloads consistent with ConstantInt::get.
llvm-svn: 102965
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 102946
|
|
|
|
|
|
|
|
| |
SimplifyICmpOperands will simplify such cases to EQ or NE. This makes
the correcntess of the code independent on SimplifyICmpOperands doing
certain simplifications.
llvm-svn: 102927
|
|
|
|
|
|
|
| |
comparison instructions, since they aren't interesting, despite having
integer result types.
llvm-svn: 102925
|
|
|
|
|
|
| |
case where both are addrecs in unrelated loops.
llvm-svn: 102924
|
|
|
|
| |
llvm-svn: 102922
|
|
|
|
|
|
| |
function as an explicit argument, for use when inlining function pointers.
llvm-svn: 102841
|
|
|
|
|
|
|
| |
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.
llvm-svn: 102830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 102823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 102798
|
|
|
|
| |
llvm-svn: 102743
|
|
|
|
|
|
|
| |
for unsigned purposes, so >64-bit integer values get a full all-ones
value.
llvm-svn: 102739
|
|
|
|
| |
llvm-svn: 102734
|
|
|
|
| |
llvm-svn: 102733
|
|
|
|
| |
llvm-svn: 102661
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 102389
|
|
|
|
|
|
|
| |
Also, generalize ScalarEvolutions's min and max recognition to handle
some new forms of min and max that this change makes more common.
llvm-svn: 102234
|