aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/InlineCost.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-02-27[InlineCost] Avoid ConstantExpr::getSelect()Nikita Popov1-3/+3
Instead use ConstantFoldSelectInstruction(), which will return nullptr if it cannot be folded and a constant expression would be produced instead. In preparation for removing select constant expressions.
2023-01-24[InlineCost] model calls to llvm.objectsize.*Nick Desaulniers1-0/+18
Very similar to https://reviews.llvm.org/D111272. We very often can evaluate calls to llvm.objectsize.* regardless of inlining. Don't count calls to llvm.objectsize.* against the InlineCost when we can evaluate the call to a constant. Link: https://github.com/ClangBuiltLinux/linux/issues/1302 Reviewed By: manojgupta Differential Revision: https://reviews.llvm.org/D111456
2023-01-11[NFC] Use TypeSize::getKnownMinValue() instead of TypeSize::getKnownMinSize()Guillaume Chatelet1-3/+3
This change is one of a series to implement the discussion from https://reviews.llvm.org/D141134.
2022-12-20[llvm] Remove redundant initialization of std::optional (NFC)Kazu Hirata1-1/+1
2022-12-16std::optional::value => operator*/operator->Fangrui Song1-6/+4
value() has undesired exception checking semantics and calls __throw_bad_optional_access in libc++. Moreover, the API is unavailable without _LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). This commit fixes LLVMAnalysis and its dependencies.
2022-12-14[Analysis] llvm::Optional => std::optionalFangrui Song1-21/+21
2022-12-04[llvm] Use std::nullopt instead of None in comments (NFC)Kazu Hirata1-2/+2
This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-02[Analysis] Use std::nullopt instead of None (NFC)Kazu Hirata1-11/+11
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-11-25[Analysis] Use std::optional in InlineCost.cpp (NFC)Kazu Hirata1-2/+3
This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-09-25[Analysis] Introduce getStaticBonusApplied (NFC)Kazu Hirata1-2/+9
InlineCostCallAnalyzer encourages inlining of the last call to the static function by subtracting LastCallToStaticBonus from Cost. This patch introduces getStaticBonusApplied to make available the amount of LastCallToStaticBonus applied. The intent is to allow the module inliner to determine whether inlining a given call site is expected to reduce the caller size with an expression like: IC.getCost() + IC.getStaticBonusApplied() < 0 This patch does not add a use of getStaticBonus yet. Differential Revision: https://reviews.llvm.org/D134373
2022-09-17[Analysis] Introduce isSoleCallToLocalFunction (NFC)Kazu Hirata1-8/+10
We check to see if a given CallBase is a sole call to a local function at multiple places in InlineCost.cpp. This patch factors out the common code. Differential Revision: https://reviews.llvm.org/D134114
2022-08-18[CostModel] Replace getUserCost with getInstructionCostSimon Pilgrim1-6/+6
* Replace getUserCost with getInstructionCost, covering all cost kinds. * Remove getInstructionLatency, it's not implemented by any backends, and we should fold the functionality into getUserCost (now getInstructionCost) to make it easier for targets to handle the cost kinds with their existing cost callbacks. Original Patch by @samparker (Sam Parker) Differential Revision: https://reviews.llvm.org/D79483
2022-08-12[Inlining] Introduce the function attribute "inline-max-stacksize"Wolfgang Pieb1-6/+21
The value of the attribute is a size in bytes. It has the effect of suppressing inlining of functions whose stacksizes exceed the given value. Reviewed By: mtrofin Differential Revision: https://reviews.llvm.org/D129904
2022-08-05[NFC][Inliner] Add Load/Store handlerVitaly Buka1-0/+13
This is an additional signal which may benefit sanitizers. Reviewed By: kda Differential Revision: https://reviews.llvm.org/D131129
2022-08-03[NFC][Inliner] Add cl::opt<int> to tune InstrCostVitaly Buka1-36/+40
The plan is tune this for sanitizers. Differential Revision: https://reviews.llvm.org/D131123
2022-08-03[NFC][Inliner] Simplify clamping in addCostVitaly Buka1-6/+6
2022-08-03[NFC][inline] Add const to an argumentVitaly Buka1-1/+1
2022-07-24[llvm] Remove redundaunt virtual specifiers (NFC)Kazu Hirata1-2/+2
Identified with modernize-use-override.
2022-07-13[llvm] Use value instead of getValue (NFC)Kazu Hirata1-4/+4
2022-07-08[Inliner] Make recusive inlinee stack size limit tunableWenlei He1-2/+7
For recursive callers, we want to be conservative when inlining callees with large stack size. We currently have a limit `InlineConstants::TotalAllocaSizeRecursiveCaller`, but that is hard coded. We found the current limit insufficient to suppress problematic inlining that bloats stack size for deep recursion. This change adds a switch to make the limit tunable as a mitigation. Differential Revision: https://reviews.llvm.org/D129411
2022-06-30Remove unneeded cl::ZeroOrMore. NFCFangrui Song1-1/+0
2022-06-30[InlineCost] Simplify constant foldingNikita Popov1-38/+12
Use a common ConstantFoldInstOperands-based constant folding implementation, instead of specifying the folding function for each function individually. Going through the generic handling doesn't appear to have any significant compile-time impact. As the test change shows, this is not NFC, because we now use DataLayout-aware constant folding, which can do slightly better in some cases (e.g. those involving GEPs).
2022-06-28[IR] Remove support for extractvalue constant expressionNikita Popov1-1/+1
This removes the extractvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. extractvalue is already not supported in bitcode, so we do not need to worry about bitcode auto-upgrade. Uses of ConstantExpr::getExtractValue() should be replaced with IRBuilder::CreateExtractValue() (if the fact that the result is constant is not important) or ConstantFoldExtractValueInstruction() (if it is). Though for this particular case, it is also possible and usually preferable to use getAggregateElement() instead. The C API function LLVMConstExtractValue() is removed, as the underlying constant expression no longer exists. Instead, LLVMBuildExtractValue() should be used (which will constant fold or create an instruction). Depending on the use-case, LLVMGetAggregateElement() may also be used instead. Differential Revision: https://reviews.llvm.org/D125795
2022-06-25[llvm] Don't use Optional::hasValue (NFC)Kazu Hirata1-3/+3
This patch replaces Optional::hasValue with the implicit cast to bool in conditionals only.
2022-06-25Revert "Don't use Optional::hasValue (NFC)"Kazu Hirata1-7/+7
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25Don't use Optional::hasValue (NFC)Kazu Hirata1-7/+7
2022-06-24[InlineCost] Improve debugging experience by adding print about initial ↵Dawid Jurczak1-0/+2
inlining cost Differential Revision: https://reviews.llvm.org/D127597
2022-06-23[Inline] Introduce a backend option to suppress inlining of functions with ↵Wolfgang Pieb1-0/+13
large stack sizes. The hidden option max-inline-stacksize=<N> prevents the inlining of functions with a stack size larger than N. Reviewed By: mtrofin, aeubanks Differential Review: https://reviews.llvm.org/D127988
2022-06-20[llvm] Don't use Optional::getValue (NFC)Kazu Hirata1-5/+5
2022-06-20[llvm] Don't use Optional::hasValue (NFC)Kazu Hirata1-1/+1
2022-06-09[NFC] format InstructionSimplify & lowerCaseFunctionNamesSimon Moll1-3/+3
Clang-format InstructionSimplify and convert all "FunctionName"s to "functionName". This patch does touch a lot of files but gets done with the cleanup of InstructionSimplify in one commit. This is the alternative to the less invasive clang-format only patch: D126783 Reviewed By: spatel, rengolin Differential Revision: https://reviews.llvm.org/D126889
2022-06-05Remove unneeded cl::ZeroOrMore for cl::opt/cl::list optionsFangrui Song1-4/+0
2022-06-04Remove unneeded cl::ZeroOrMore for cl::opt optionsFangrui Song1-1/+1
Similar to 557efc9a8b68628c2c944678c6471dac30ed9e8e. This commit handles options where cl::ZeroOrMore is more than one line below cl::opt.
2022-06-03[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFCFangrui Song1-8/+8
Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!` error. More were added due to cargo cult. Since the error has been removed, cl::ZeroOrMore is unneeded. Also remove cl::init(false) while touching the lines.
2022-04-24[InlineCost] Set LastCallToStaticBonus in ML inlining models.Jun Ma1-0/+4
This patch set LastCallToStaticBonus based on check, it has no noticeable size reduction on an internal workload and linux kernel with Os/Oz. Differential Revision: https://reviews.llvm.org/D124233
2022-04-12[InlineCost] Check that function types matchNikita Popov1-3/+3
Retain the behavior we get without opaque pointers: A call to a known function with different function type is considered an indirect call. This fixes the crash reported in https://reviews.llvm.org/D123300#3444772.
2022-04-03CallBase: fix getFnAttr so it also checks the functionAugie Fackler1-20/+1
Prior to this change, CallBase::hasFnAttr checked the called function to see if it had an attribute if it wasn't set on the CallBase, but getFnAttr didn't do the same delegation, which led to very confusing behavior. This patch fixes the issue by making CallBase::getFnAttr also check the function under the same circumstances. Test changes look (to me) like they're cleaning up redundant attributes which no longer get specified both on the callee and call. We also clean up the one ad-hoc implementation of this getter over in InlineCost.cpp. Differential Revision: https://reviews.llvm.org/D122821
2022-03-11[InlineCost] Add cl::opt for target attributes compatibility check. NFCAnna Thomas1-1/+12
This patch adds a CL option for avoiding the attribute compatibility check between caller and callee in TTI. TTI attribute compatibility checks for target CPU and target features. In our downstream compiler, this attribute always remains the same between callee and caller. By avoiding the addition of this attribute to each of our inline candidate (and then checking them here during inline cost), we save some compile time. The option is kept false, so this change is an NFC upstream.
2022-03-07[NewPM][Inliner] Make inlined calls to functions in same SCC as callee ↵Arthur Eubanks1-2/+11
exponentially expensive Introduce a new attribute "function-inline-cost-multiplier" which multiplies the inline cost of a call site (or all calls to a callee) by the multiplier. When processing the list of calls created by inlining, check each call to see if the new call's callee is in the same SCC as the original callee. If so, set the "function-inline-cost-multiplier" attribute of the new call site to double the original call site's attribute value. This does not happen when the original call site is intra-SCC. This is an alternative to D120584, which marks the call sites as noinline. Hopefully fixes PR45253. Reviewed By: davidxl Differential Revision: https://reviews.llvm.org/D121084
2022-03-01Cleanup includes: LLVMAnalysisserge-sans-paille1-1/+1
Number of lines output by preprocessor: before: 1065940348 after: 1065307662 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D120659
2022-02-28[InlineCost] Use SmallPtrSet for DeadBlocks (NFC)Nikita Popov1-2/+2
This set is only used with contains operations, so there is no need to use a SetVector.
2022-02-14[Inliner] Respect noinline call site attributeDávid Bolvanský1-0/+3
``` always_inline foo() { } bar () { noinline foo(); } ``` We should prefer call site attribute over attribute on decl. Related to https://reviews.llvm.org/D119061 Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D119579
2022-02-06[llvm] Use = default (NFC)Kazu Hirata1-2/+2
2022-01-23[Analysis] Use default member initialization (NFC)Kazu Hirata1-4/+3
Identified with modernize-use-default-member-init.
2022-01-13Don't override __attribute__((no_stack_protector)) by inlining (PR52886)Hans Wennborg1-9/+0
Since 26c6a3e736d3, LLVM's inliner will "upgrade" the caller's stack protector attribute based on the callee. This lead to surprising results with Clang's no_stack_protector attribute added in 4fbf84c1732f (D46300). Consider the following code compiled with clang -fstack-protector-strong -Os (https://godbolt.org/z/7s3rW7a1q). extern void h(int* p); inline __attribute__((always_inline)) int g() { return 0; } int __attribute__((__no_stack_protector__)) f() { int a[1]; h(a); return g(); } LLVM will inline g() into f(), and f() would get a stack protector, against the users explicit wishes, potentially breaking the program e.g. if h() changes the value of the stack cookie. That's a miscompile. More recently, bc044a88ee3c (D91816) addressed this problem by preventing inlining when the stack protector is disabled in the caller and enabled in the callee or vice versa. However, the problem remained if the callee is marked always_inline as in the example above. This affected users, see e.g. http://crbug.com/1274129 and http://llvm.org/pr52886. One way to fix this would be to prevent inlining also in the always_inline case. Despite the name, always_inline does not guarantee inlining, so this would be legal but potentially surprising to users. However, I think the better fix is to not enable the stack protector in a caller based on the callee. The motivation for the old behaviour is unclear, it seems counter-intuitive, and causes real problems as we've seen. This commit implements that fix, which means in the example above, g() gets inlined into f() (also without always_inline), and f() is emitted without stack protector. I think that matches most developers' expectations, and that's also what GCC does. Another effect of this change is that a no_stack_protector function can now be inlined into a stack protected function, e.g. (https://godbolt.org/z/hafP6W856): extern void h(int* p); inline int __attribute__((__no_stack_protector__)) __attribute__((always_inline)) g() { return 0; } int f() { int a[1]; h(a); return g(); } I think that's fine. Such code would be unusual since no_stack_protector is normally applied to a program entry point which sets up the stack canary. And even if such code exists, inlining doesn't change the semantics: there is still no stack cookie setup/check around entry/exit of the g() code region, but there may be in the surrounding context, as there was before inlining. This also matches GCC. See also the discussion at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722 Differential revision: https://reviews.llvm.org/D116589
2021-11-14[llvm] Use isa instead of dyn_cast (NFC)Kazu Hirata1-2/+2
2021-11-14[NFC] Use Optional<ProfileCount> to model invalid countsMircea Trofin1-3/+3
ProfileCount could model invalid values, but a user had no indication that the getCount method could return bogus data. Optional<ProfileCount> addresses that, because the user must dereference the optional. In addition, the patch removes concept duplication. Differential Revision: https://reviews.llvm.org/D113839
2021-10-18[InlineCost] Add empty line between call sites when printing inline costsArthur Eubanks1-6/+7
2021-10-14Fix getInlineCost with ComputeFullInlineCost enabledArtur Pilipenko1-9/+23
Fix a bug when getInlineCost incorrectly returns a cost/threshold pair instead of an explicit never inline. Reviewed By: mtrofin Differential Revision: https://reviews.llvm.org/D111687
2021-10-12[CSSPGO] Unblock optimizations with pseudo probe instrumentation part 3.Hongtao Yu1-5/+2
This patch continues unblocking optimizations that are blocked by pseudo probe instrumentation. Not exactly like DbgIntrinsics, PseudoProbe intrinsic has other attributes (such as mayread, maywrite, mayhaveSideEffect) that can block optimizations. The issues fixed are: - Flipped default param of getFirstNonPHIOrDbg API to skip pseudo probes - Unblocked CSE by avoiding pseudo probe from clobbering memory SSA - Unblocked induction variable simpliciation - Allow empty loop deletion by treating probe intrinsic isDroppable - Some refactoring. Reviewed By: wenlei Differential Revision: https://reviews.llvm.org/D110847
generated by cgit v1.1 at 2025-10-16 00:04:38 +0000