summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/InlineCost.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Extend the inline cost calculation to account for bonuses due toChandler Carruth2012-03-141-3/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | correlated pairs of pointer arguments at the callsite. This is designed to recognize the common C++ idiom of begin/end pointer pairs when the end pointer is a constant offset from the begin pointer. With the C-based idiom of a pointer and size, the inline cost saw the constant size calculation, and this provides the same level of information for begin/end pairs. In order to propagate this information we have to search for candidate operations on a pair of pointer function arguments (or derived from them) which would be simplified if the pointers had a known constant offset. Then the callsite analysis looks for such pointer pairs in the argument list, and applies the appropriate bonus. This helps LLVM detect that half of bounds-checked STL algorithms (such as hash_combine_range, and some hybrid sort implementations) disappear when inlined with a constant size input. However, it's not a complete fix due the inaccuracy of our cost metric for constants in general. I'm looking into that next. Benchmarks showed no significant code size change, and very minor performance changes. However, specific code such as hashing is showing significantly cleaner inlining decisions. llvm-svn: 152752
* Refactor the inline cost bonus calculation for constants to useChandler Carruth2012-03-141-20/+26
| | | | | | | | a worklist rather than a recursive call. No functionality changed. llvm-svn: 152706
* Make helper static, so it can be inlined into its sole caller.Benjamin Kramer2012-03-101-3/+3
| | | | llvm-svn: 152515
* Undo a previous restriction on the inline cost calculation which NickChandler Carruth2012-03-091-107/+146
| | | | | | | | | | | | | | | | | | | | | | introduced. Specifically, there are cost reductions for all constant-operand icmp instructions against an alloca, regardless of whether the alloca will in fact be elligible for SROA. That means we don't want to abort the icmp reduction computation when we abort the SROA reduction computation. That in turn frees us from the need to keep a separate worklist and defer the ICmp calculations. Use this new-found freedom and some judicious function boundaries to factor the innards of computing the cost factor of any given instruction out of the loop over the instructions and into static helper functions. This greatly simplifies the code, and hopefully makes it more clear what is happening here. Reviewed by Eric Christopher. There is some concern that we'd like to ensure this doesn't get out of hand, and I plan to benchmark the effects of this change over the next few days along with some further fixes to the inline cost. llvm-svn: 152368
* Rotate two of the functions used to count bonuses for the inline costChandler Carruth2012-03-081-14/+10
| | | | | | | | | | | | | analysis to be methods on the cost analysis's function info object instead of the code metrics object. These really are just users of the code metrics, they're building the information for the function's analysis. This is the first step of growing the amount of information we collect about a function in order to cope with pair-wise simplifications due to allocas. llvm-svn: 152283
* Use precomputed BB size instead of BB->size().Nick Lewycky2012-01-251-1/+1
| | | | llvm-svn: 148964
* Support pointer comparisons against constants, when looking at the inline-costNick Lewycky2012-01-251-1/+55
| | | | | | | | | 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
* Fix CountCodeReductionForAlloca to more accurately represent what SROA can andNick Lewycky2012-01-201-16/+60
| | | | | | | | 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
* Continue counting intrinsics as instructions (except when they aren't, such asNick Lewycky2011-12-211-3/+17
| | | | | | debug info) and for being vector operations. Fixes regression from r147037. llvm-svn: 147093
* Fix typo and spacing, no functionality change.Nick Lewycky2011-12-211-2/+2
| | | | llvm-svn: 147092
* A call to a function marked 'noinline' is not an inline candidate. The soleNick Lewycky2011-12-211-4/+4
| | | | | | | 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
* Allow inlining of functions with returns_twice calls, if they have theJoerg Sonnenberger2011-12-181-6/+8
| | | | | | attribute themselve. llvm-svn: 146851
* A FIXME about block addresses and indirectbr.Eli Friedman2011-10-201-0/+6
| | | | llvm-svn: 142569
* Correct over-zealous removal of hack.Bill Wendling2011-10-171-1/+1
| | | | | | | 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
* Now that we have the ReturnsTwice function attribute, this method isBill Wendling2011-10-171-6/+5
| | | | | | | obsolete. Check the attribute instead. <rdar://problem/8031714> llvm-svn: 142212
* Inlining and unrolling heuristics should be aware of free truncs.Andrew Trick2011-10-011-12/+20
| | | | | | | | | | 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
* whitespaceAndrew Trick2011-10-011-46/+46
| | | | llvm-svn: 140916
* Change condition for determining whether a function is small for inlining ↵Eli Friedman2011-05-241-1/+1
| | | | | | | | metrics so that very long functions with few basic blocks are not re-analyzed. llvm-svn: 131994
* Extra refactoring noticed by Eli Friedman.Rafael Espindola2011-05-161-9/+8
| | | | llvm-svn: 131405
* Fix a ton of comment typos found by codespell. Patch byChris Lattner2011-04-151-2/+2
| | | | | | Luis Felipe Strano Moraes! llvm-svn: 129558
* Remove premature optimization that avoided calculating argument weightsEric Christopher2011-02-061-5/+0
| | | | | | | | | if we weren't going to inline the function. The rest of the code using this was removed. Fixes PR9154. llvm-svn: 124991
* Fix cut and paste error spotted by Jakob.Eric Christopher2011-02-051-1/+1
| | | | llvm-svn: 124930
* Rewrite how the indirect call bonus is handled. This now works by:Eric Christopher2011-02-051-78/+125
| | | | | | | | | | | | | | | | | 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
* Reapply 124275 since the Dragonegg failure was unreproducible.Eric Christopher2011-02-011-82/+85
| | | | llvm-svn: 124641
* Temporarily revert 124275 to see if it brings the dragonegg buildbot back.Eric Christopher2011-01-261-85/+82
| | | | llvm-svn: 124312
* Separate out the constant bonus from the size reduction metrics. ReworkEric Christopher2011-01-261-82/+85
| | | | | | | | | 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
* Coding style formatting changes.Eric Christopher2011-01-261-7/+2
| | | | llvm-svn: 124260
* Reorganize this so that the early exit and special cases come earlyEric Christopher2011-01-251-26/+26
| | | | | | rather than interspersed. No functional change. llvm-svn: 124168
* Add a FIXME explaining the move to a single indirect call bonus per functionEric Christopher2011-01-221-0/+5
| | | | | | that we can change from indirect to direct. llvm-svn: 124045
* Only apply the devirtualization bonus once instead of per-call site in theEric Christopher2011-01-221-2/+6
| | | | | | | | target function. Fixes part of rdar://8546196 llvm-svn: 124044
* Now using a variant of the existing inlining heuristics to decide whether to ↵Kenneth Uildriks2010-10-091-0/+70
| | | | | | 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
* Start separating out code metrics into code size metrics and code ↵Kenneth Uildriks2010-10-081-10/+53
| | | | | | 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
* What the loop unroller cares about, rather than just not unrolling loops ↵Owen Anderson2010-09-091-0/+6
| | | | | | | | | | | 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
* Refactor code-size reduction estimation methods out of InlineCostAnalyzer ↵Owen Anderson2010-09-091-92/+90
| | | | | | | | | | | 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
* use ImmutableCallSite for const-corrgoodnessGabor Greif2010-07-271-4/+4
| | | | llvm-svn: 109503
* Pulled CodeMetrics out of InlineCost.h and made it a bit more general, so it ↵Kenneth Uildriks2010-06-091-7/+20
| | | | | | can be reused from PartialSpecializationCost llvm-svn: 105725
* Avoid counting InlineAsm as a call - it prevents loop unrolling.Jakob Stoklund Olesen2010-05-261-1/+5
| | | | | | | PR7026 Patch by Pekka Jääskeläinen! llvm-svn: 104780
* Clear CachedFunctionInfo upon Pass::releaseMemory. Because ValueMap will abortNick Lewycky2010-05-121-1/+6
| | | | | | | | | | 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
* Added a variant of InlineCostAnalyzer::getInlineCost() that takes the called ↵David Chisnall2010-05-011-3/+9
| | | | | | function as an explicit argument, for use when inlining function pointers. llvm-svn: 102841
* Dan recently disabled recursive inlining within a function, but weChris Lattner2010-04-301-1/+9
| | | | | | | | | | | | | | | | | | 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
* Revert r101471. For tight recursive functions which have multipleDan Gohman2010-04-211-7/+0
| | | | | | | | | 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
* fix PR6858: a dangling pointer use bug which was causedChris Lattner2010-04-171-1/+8
| | | | | | | | | | | | 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
* a bunch of cleanups and tweaks, no functionality changes.Chris Lattner2010-04-171-42/+48
| | | | llvm-svn: 101657
* Disable inlining of recursive calls. It can complicate tailcallelim andDan Gohman2010-04-161-0/+7
| | | | | | | dependent analyses, and increase code size, so doing it profitably would require more complex heuristics. llvm-svn: 101471
* Make callIsSmall accessible as a utility function.Dan Gohman2010-04-161-4/+4
| | | | llvm-svn: 101463
* performance: cache the dereferenced use_iteratorGabor Greif2010-04-141-7/+8
| | | | llvm-svn: 101265
* Reapply r99451 with a fix to move the NoInline check to the cost functionsEric Christopher2010-03-251-2/+4
| | | | | | instead of InlineFunction. llvm-svn: 99483
* Treat copysignl like the other copysign functions.Duncan Sands2010-03-151-1/+1
| | | | llvm-svn: 98542
* Do not ignore arg_size() impact while counting bb instructions.Devang Patel2010-03-131-3/+2
| | | | llvm-svn: 98408
* Remove extra parameter.Devang Patel2010-03-131-5/+4
| | | | llvm-svn: 98403
OpenPOWER on IntegriCloud