More control over inlining

[tisztamo]

The current inlining algorithm, although works well in most cases, uses a cost model that is "extremely simple and ignores many important details". It seems not easy to improve the algorithm significantly, though.

On the other hand, the user can only suggest their wish to inline something with @inline: a binary flag applied at method declaration, weakly affecting every call of that method.

This combination leads to cases where the compiler denies the user's wish based on an incorrect cost estimation. It happens for example when the method body contains a dynamically dispatched call, even if it is called infrequently (or never), thanks to aggressive type-stabilization techniques. (e.g. ManualDispatch.jl, Catwalk.jl) .

More generally, providing composable zero-cost abstractions to end users without the ability to control inlining is very hard, if not impossible.

An example is our attempt with @tkf to integrate Catwalk.jl with the JuliaFolds ecosystem: JuliaFolds/FoldsCatwalk.jl#1 (comment)

I see two possible solutions:

1. @inline force=F

Where force is a multiplier applied to the inlining threshold.

@inline force=20 Transducers.next(rf::R_{OptimizeXF}, acc, @nospecialize(input)) = ...

Here input is Any, and the declared method will do the type-stabilization.

2. @force-inline at the call site

Forcing inlining at the call site seems less risky to me in terms of accidental compilation overhead. If only calls to @inline-marked methods can be forced, the risk may be reduced even further.

[non-Jedi]

Note that issue #18773 already exists for point 2.

[tisztamo]

Thanks, I did not know about that, and #41328 looks great!

There is a difference though: Here the user forces inlining by completely ignoring the cost model, while in #18773 and IIUC #41328 only the control is moved to the call site, the inlining can be still denied by the compiler.

[tisztamo]

My understanding was incorrect, #41328 will close this!