Current guidance on use of '@alwaysinline` & `@inline`?

[LeeTibbert]

What is the current informed guidance on the use of the @alwaysinline and @inline annotations?

The days I am seeing an increased and liberal use of @alwaysinline. I do not want to be giving out outdated responses when I see them and think they are unnecessary or worse.

Traditional SN guidance has been to use @alwaysinline only where strictly necessary and @inline sparingly. This allows the compiler to apply any knowledge it has at that point as to the most efficient code.

I suspect that a lot of the recent @alwaysinline has been done without measurement or analysis.

In this discussion, I am assuming that the SN compiler has been invoked with a mode that allows optimization passes.

I would expect the compiler to automatically inline an expression such as def abc(d, e) = (d == e). I can somewhat understand @alwaysinline in that context. If that optimization is not being detected, such might reduce overall code size, register usage, and execution time.

I would also expect a competent compiler to detect def abc(d) = d.foo() and generate one call frame rather than two. Does the SN compiler need @alwaysinline to detect that? Can the less demanding @inline hint be used? Functional code tends to direct chaining of calls quite a bit.

My concern is that a lot of these @alwaysinline are not in loops and are usually used once and not in places where execution speed of that exact section is critical; i.e. have little benefit but cost readers of the code time to unravel the "Why??!".

[WojciechMazur]

Thank you for bringing this to attention! I also, might have been too liberal about that.

In general, unless you're in critical path don't bother about annotating. Most of our code can be left without these. Optimiser can still choose to inline, most of the examples above would be inlined, unless given code can throw or the context is already too large. We might need to to recheck current usage, and maybe remove some of these annotations in the future if these are not necessary. Most of these should however be documented in benchmarks for both code size and performance, before removing them...which on it's own might be a large task already.

[LeeTibbert]

Wojciech,

Thank you for the current information. Gratifying to know that the SN compiler continues to silently inline the cases where I had expected it to do so.

The information about what prevents automatic inlining was interesting, specially the Exception part.

I concur that removing existing usages is hazardous and requires evidence.

My concern is with giving the correct & current advice when reading new library code. Your reply establishes current "best practice".