pkarashchenko commented on pull request #5201: URL: https://github.com/apache/incubator-nuttx/pull/5201#issuecomment-1009395485
> > > How about applying this change only to the `static inline` functions from header files and simply removing the `inline` keyword from functions defined in source/implementation files? > > > Usually the compiler is smart enough to decide whether a function should be inlined and the `always_inline` attribute may induce an unintended increase on code size. > > > > Or as an alternative we can introduce `inline_function` and `forceinline_function` so that can be selectable in header and source code files. > > Sorry, maybe I understood it incorrectly, but would both macros be defined to the same `always_inline` attribute? If that is the case, this will end up confusing. > I would agree with renaming the `inline_function` macro to `forceinline_function`, makes it more intuitive this way. Unfortunately, afaik, there is no function attribute to 1:1 substitute the `inline` keyword, to just give a hint to the compiler. So, for these cases, I think we'd better just trust the compiler's optimization passes to perform the necessary inlining. Currently in code there are two qualifiers used for inline functions: 1. `inline` -- the C99 extension 2. `inline_funtion` -- that basically is a "force inline" directive to compilers that support it. We need common code to be C89 compatible, so most probably need to replace both cases with macro definitions. For now I do not know compilers that support force inlining but do not support `inline` keyword one or another way (I mean that some compilers support `__inline` instead of `inline` but with the same meaning). In this initial change I start replacing `inline` with `inline_function` (that is currently a force inline actually) so now I'm thinking of: 1. Rework `inline_function` to be replacement for `inline` 2. Introduce new `force_inline` to handle force inline case (the current `inline_function`). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org