llvm / llvm/llvm-project

[Inliner] Inline cost model misses caller-side simplifications enabled by inlining

Open
#223,012 0 comments 0 reactions 0 assignees View on GitHub
llvm:optimizations missed-optimization
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

Godbolt Link: https://godbolt.org/z/GGcxnWxdK

In the testcase, makeSize() is expensive enough that Clang does not inline it at the normal inline threshold.

However, makeSize() preserves the size value encoded in size_ across the call. In this case, the size is known to be zero before the call and remains zero after the call.

When makeSize() is not inlined, this fact is hidden across the call boundary and substantial size-dependent code remains in the caller.

When the inline threshold is increased enough for makeSize() to inline, the resulting loads and stores become visible to the normal optimization pipeline. LLVM can then determine that the size remains zero and eliminate a significant amount of caller-side code.

The important benefit is therefore not primarily in the candidate but in the caller code:

inline makeSize()

memory effects become visible in the caller

size is proven to remain zero

subsequent caller code folds away

This appears to be a missed inline-profitability case where the candidate has a relatively high local inline cost, but inlining enables substantial simplification in the caller. The current inline cost model does not appear to account for this caller-side simplification.
Caller-side simplification as part of the inline cost model was also being discussed here: https://discourse.llvm.org/t/approaches-to-the-inliner-blowing-up/89971

The testcase is reduced from Folly's small_vector implementation:
https://github.com/facebook/folly/blob/main/folly/container/small_vector.h

Should this kind of case be handled by extending the inline profitability model to account for caller-side simplifications, or is this better handled by another interprocedural analysis/optimization?

Contributor guide

Open the contributing guide

Research direction

Start with the reduced Godbolt testcase at https://godbolt.org/z/GGcxnWxdK and compare the generated code with and without inlining. Read the LLVM inliner cost model and the caller-side discussion linked in the issue, then use Folly's small_vector.h as context. Done means establishing a regression test and an agreed implementation that accounts for the caller simplification or routes it to another analysis.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.