Bots, Bureaucrats, Interface administrators, smwadministrator, smwcurator, smweditor, Administrators
2,558
edits
Inline Transformation: Difference between revisions
Jump to navigation
Jump to search
→Clang/LLVM Inline Implementation
Timo.stripf (talk | contribs) |
Timo.stripf (talk | contribs) |
||
| Line 55: | Line 55: | ||
=== Clang/LLVM Inline Implementation === | === Clang/LLVM Inline Implementation === | ||
== LLVM Inlining Implementation == | |||
LLVM uses a cost-based heuristic to decide whether a function should be inlined at a given call site. This decision is primarily handled by the `InlineCost` analysis, located in the files `InlineCost.cpp` and `InlineCost.h`. The inline parameters that influence this decision are encapsulated in the `InlineParams` structure. | |||
The `InlineParams` structure defines the thresholds and conditions that govern LLVM’s inlining decisions. These values vary based on the optimization level (`-O0` to `-O3`). | |||
{| class="wikitable" | |||
|+ InlineParams Structure | |||
! Parameter !! Description !! Default Values | |||
|- | |||
| `DefaultThreshold` || Standard threshold for inlining decisions. If the computed inline cost is below this value, the function is likely to be inlined. || `0` (`-O0`), `75` (`-O1`), `225` (`-O2`), `275` (`-O3`) | |||
|- | |||
| `HintThreshold` || Threshold for functions marked as `inline`, influencing their likelihood of being inlined. || Higher than `DefaultThreshold` | |||
|- | |||
| `ColdThreshold` || Lower threshold for cold functions that are rarely executed. || Lower than `DefaultThreshold` | |||
|- | |||
| `OptSizeThreshold` || Threshold when optimizing for size (`-Os`). || Lower than `DefaultThreshold` | |||
|- | |||
| `OptMinSizeThreshold` || Threshold when optimizing for minimal size (`-Oz`). || Lower than `OptSizeThreshold` | |||
|- | |||
| `HotCallSiteThreshold` || Increased threshold for call sites that are frequently executed (hot paths). || Higher than `DefaultThreshold` | |||
|- | |||
| `LocallyHotCallSiteThreshold` || Threshold for call sites considered locally hot relative to their function entry. || Similar to `HotCallSiteThreshold` | |||
|- | |||
| `ColdCallSiteThreshold` || Threshold for cold call sites, discouraging inlining. || Lower than `DefaultThreshold` | |||
|- | |||
| `ComputeFullInlineCost` || Determines whether the full inline cost should always be computed. || `true` | |||
|- | |||
| `EnableDeferral` || Allows the inlining decision to be deferred for later analysis. || `true` | |||
|- | |||
| `AllowRecursiveCall` || Specifies whether recursive functions are allowed to be inlined. || `false` (`-O0` to `-O2`), `true` (`-O3`) | |||
|} | |||
* [https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/InlineCost.cpp LLVM InlineCost.cpp on GitHub] | |||
* [https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Analysis/InlineCost.h LLVM InlineCost.h on GitHub] | |||
One difference to mention is that Clang’s diagnostics and reports can help understand inlining decisions. For example, Clang has flags like <code>-Rpass=inline</code> and <code>-Rpass-missed=inline</code> which, at compile time, can report which functions were inlined or not inlined and why. This can be useful to tune code for inlining with Clang. The heuristics themselves (function size thresholds, etc.) are continuously refined in LLVM’s development, but generally align with the goal of balancing performance gain against code growth. | One difference to mention is that Clang’s diagnostics and reports can help understand inlining decisions. For example, Clang has flags like <code>-Rpass=inline</code> and <code>-Rpass-missed=inline</code> which, at compile time, can report which functions were inlined or not inlined and why. This can be useful to tune code for inlining with Clang. The heuristics themselves (function size thresholds, etc.) are continuously refined in LLVM’s development, but generally align with the goal of balancing performance gain against code growth. | ||