Compiler telling me to inline functions that are already inline

The compiler inlines functions only when you build with optimization.  What compiler are you using?  Please show the build options as the compiler sees them.

Thanks and regards,

-George

I forgot to mention I'm using an MSP430.

I'm not using any optimization right now. I thought optimization would only allow automatic inlining, but using the inline keyword would inline function even without optimization turned on.

Are you saying the inline keyword is ignored unless optimization is turned on?

From the user manual, it looks like whether the compiler inlines a function declared as inline is complicated. In most circumstances it will not inline the function even if it is legal to do so.

The optimizer will aggressively try to inline a function declared inline. There are many things about the function which may prevent this, but they are mostly rare cases. What about the documentation gives you the impression that in "most circumstances" it will not inline the function?

-opt_level off = no inline
-opt_level < 3 = no inline
-opt_level >= 3 = maybe inline

There are 5 optimization levels and off. Only two of those levels allow inlining at all without using the FUNC_ALWAYS_INLINE pragma. However even the two levels that allow inlining won't inline all the time. It depends on how optimized for speed is set, and whether the compiler thinks the function is a good candidate for inlining (which is something different than whether it's a valid candidate). So out of 6 possible settings maybe two of them will inline a function. In other words, in most cases the function will not be inlined. I would have thought that if I specifically give the compiler a valid instruction that it would execute the instruction regardless of what the compiler thinks is correct. I guess it does act that way if I use the pragma mentioned, which is a little like saying, "If I tell you to inline something, I really mean it."

I think maybe the compiler advice is just confusing: the compiler is advising me to inline a function when it is the compiler itself that is preventing it from being inlined. It's a little like someone punching me in the face, and then telling me to stop smashing my nose against their fist. The advice should probably say something like, "this function will not be inlined even though it is declared as inline."

I'm not saying any of this is bad or wrong, but I find it a bit confusing. I got it now though. Thanks for the help.

In this case, the advice message should be enhanced to suggest enabling the optimizer. This is a usability issue.

Regarding inlining versus the optimization level, it works more like the following. (Note: this is a bit simplified.) Will a function be inlined?

opt level	inline keyword used	inline keyword not used
off	no	no
0	maybe	no
1	maybe	no
2	maybe	no
3	maybe	maybe
4	maybe	maybe

Unfortunately, there is some muddled wording in section 2.11 of the compiler manual.

To expand on the table above:  the optimiser stage of the compiler is where inlining happens, therefore you must use at least -o0 if you want inlining.  Inlining of functions declared inline is not affected by optimisation for speed;  the only reason the compiler will decline to inline such a function is if it thinks it risks crashing the compiler due to excessive function size.

Inlining for MSP (and C2000, but not C6000 or ARM) is complicated by an internal restriction that either all calls to a function be inlined, or none of them;  it can't do just some.  That's one motivation for the FUNC_ALWAYS_INLINE pragma, to override the compiler's estimate of risk.  Of course, if the compiler does crash, the first suggestion will be to remove that pragma.

Auto-inlining does depend on optimisation level and optimisation for speed (and the size specified by --auto_inline) -- the compiler is picking functions that the user didn't indicate, and trying to improve speed while not costing too much in code size.  We don't want that to happen by surprise, and there should be some control, hence the limits and restrictions.

Yes, the compiler shouldn't give confusing advice;  we need to clean that up.  Thanks for bringing the advice and documentation problems to light.