| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 148964
|
|
|
|
|
|
|
|
|
| |
savings from a pointer argument becoming an alloca. Sometimes callees will even
compare a pointer to null and then branch to an otherwise unreachable block!
Detect these cases and compute the number of saved instructions, instead of
bailing out and reporting no savings.
llvm-svn: 148941
|
|
|
|
|
|
|
|
| |
can't handle. Also don't produce non-zero results for things which won't be
transformed by SROA at all just because we saw the loads/stores before we saw
the use of the address.
llvm-svn: 148536
|
|
|
|
|
|
| |
debug info) and for being vector operations. Fixes regression from r147037.
llvm-svn: 147093
|
|
|
|
| |
llvm-svn: 147092
|
|
|
|
|
|
|
| |
call site of an intrinsic is also not an inline candidate. While here, make it
more obvious that this code ignores all intrinsics. Noticed by inspection!
llvm-svn: 147037
|
|
|
|
|
|
| |
attribute themselve.
llvm-svn: 146851
|
|
|
|
| |
llvm-svn: 142569
|
|
|
|
|
|
|
| |
Some code want to check that *any* call within a function has the 'returns
twice' attribute, not just that the current function has one.
llvm-svn: 142221
|
|
|
|
|
|
|
| |
obsolete. Check the attribute instead.
<rdar://problem/8031714>
llvm-svn: 142212
|
|
|
|
|
|
|
|
|
|
| |
We want heuristics to be based on accurate data, but more importantly
we don't want llvm to behave randomly. A benign trunc inserted by an
upstream pass should not cause a wild swings in optimization
level. See PR11034. It's a general problem with threshold-based
heuristics, but we can make it less bad.
llvm-svn: 140919
|
|
|
|
| |
llvm-svn: 140916
|
|
|
|
|
|
|
|
| |
metrics so that very long functions
with few basic blocks are not re-analyzed.
llvm-svn: 131994
|
|
|
|
| |
llvm-svn: 131405
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
|
|
|
|
|
|
|
|
| |
if we weren't going to inline the function. The rest of the code using
this was removed.
Fixes PR9154.
llvm-svn: 124991
|
|
|
|
| |
llvm-svn: 124930
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a) Making it a per call site bonus for functions that we can move from
indirect to direct calls.
b) Reduces the bonus from 500 to 100 per call site.
c) Subtracts the size of the possible newly inlineable call from the
bonus to only add a bonus if we can inline a small function to devirtualize
it.
Also changes the bonus from a positive that's subtracted to a negative
that's added.
Fixes the remainder of rdar://8546196 by reducing the object file size
after inlining by 84%.
llvm-svn: 124916
|
|
|
|
| |
llvm-svn: 124641
|
|
|
|
| |
llvm-svn: 124312
|
|
|
|
|
|
|
|
|
| |
a few loops accordingly. Should be no functional change.
This is a step for more accurate cost/benefit analysis of devirt/inlining
bonuses.
llvm-svn: 124275
|
|
|
|
| |
llvm-svn: 124260
|
|
|
|
|
|
| |
rather than interspersed. No functional change.
llvm-svn: 124168
|
|
|
|
|
|
| |
that we can change from indirect to direct.
llvm-svn: 124045
|
|
|
|
|
|
|
|
| |
target function.
Fixes part of rdar://8546196
llvm-svn: 124044
|
|
|
|
|
|
| |
create a given specialization of a function in PartialSpecialization. If the total performance bonus across all callsites passing the same constant exceeds the specialization cost, we create the specialization.
llvm-svn: 116158
|
|
|
|
|
|
| |
performance metrics. Partial Specialization will apply the former to function specializations, and the latter to all callsites that can use a specialization, in order to decide whether to create a specialization
llvm-svn: 116057
|
|
|
|
|
|
|
|
|
|
|
| |
with calls, is
not unrolling loops that contain calls that would be better off getting inlined. This mostly
comes up when an interleaved devirtualization pass has devirtualized a call which the inliner
will inline on a future pass. Thus, rather than blocking all loops containing calls, add
a metric for "inline candidate calls" and block loops containing those instead.
llvm-svn: 113535
|
|
|
|
|
|
|
|
|
|
|
| |
and into CodeMetrics. They
don't use any InlineCostAnalyzer state, and are useful for other clients who don't necessarily want to use
all of InlineCostAnalyzer's logic, some of which is fairly inlining-specific.
No intended functionality change.
llvm-svn: 113499
|
|
|
|
| |
llvm-svn: 109503
|
|
|
|
|
|
| |
can be reused from PartialSpecializationCost
llvm-svn: 105725
|
|
|
|
|
|
|
| |
PR7026
Patch by Pekka Jääskeläinen!
llvm-svn: 104780
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
function as an explicit argument, for use when inlining function pointers.
llvm-svn: 102841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
dependent analyses, and increase code size, so doing it profitably would
require more complex heuristics.
llvm-svn: 101471
|
|
|
|
| |
llvm-svn: 101463
|
|
|
|
| |
llvm-svn: 101265
|
|
|
|
|
|
| |
instead of InlineFunction.
llvm-svn: 99483
|
|
|
|
| |
llvm-svn: 98542
|
|
|
|
| |
llvm-svn: 98408
|
|
|
|
| |
llvm-svn: 98403
|
|
|
|
|
|
| |
Use CodeMetrics.analyzeBasicBlock() to estimate BB size.
llvm-svn: 98401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Caller cost info would be reset everytime a callee was inlined. If the
caller has lots of calls and there is some mutual recursion going on, the
caller cost info could be calculated many times.
This patch reduces inliner runtime from 240s to 0.5s for a function with 20000
small function calls.
This is a more conservative version of r98089 that doesn't break the clang
test CodeGenCXX/temp-order.cpp. That test relies on rather extreme inlining
for constant folding.
llvm-svn: 98099
|
|
|
|
| |
llvm-svn: 98094
|
|
|
|
|
|
|
|
|
|
|
| |
The Caller cost info would be reset everytime a callee was inlined. If the
caller has lots of calls and there is some mutual recursion going on, the
caller cost info could be calculated many times.
This patch reduces inliner runtime from 240s to 0.5s for a function with 20000
small function calls.
llvm-svn: 98089
|
|
|
|
|
|
| |
can sometimes help reduce function size.
llvm-svn: 98088
|