None of the answers here really answer the question of when you should use inline instead of always-inline, but the answer is fairly simple. You should pretty much always use inline unless you know exactly what you are doing and understand the performance implications of inlining the function you are annotating, because a bad inlining decision can in the worst case make a program much slower, and that includes both inlining when you shouldn't inline, and not inlining when you should inline. Generally speaking the compiler is quite intelligent at deciding this in the majority of cases, but it's not perfect; if it were, there would be no need for the inline keyword. It's true that the C language is quite esoteric about what precisely the inline keyword means, so you should read up before you use it, but it's better to leave ultimate say on whether to inline a function to the compiler as much as possible.
That being said, when you are optimizing critical parts of the code (and if you don't care about performance, why are you inlining things?), sometimes the compiler will make the wrong decision. In this case, you can correct the behavior with noinline or alwaysinline. But you should always familiarize yourself with the assembly of the functions in question before making this decision; too much inlining can increase code size and register pressure, and decrease cache locality. Too little can make code orders of magnitude slower.
inline
is standard and __always_inline looks like a compiler extension only for certain compilers. Btwinline
is a suggestion to the compiler. There is no guarantee that it will be inlined. – Nonpayment