Inlined code

[Christian Mauderer]

Am 05.08.2018 um 04:00 schrieb Chris Johns:
> Hi,
> 
> I have been working on migrating covoar in the rtems-tools repo to DWARF. The
> goal is remove objdump parsing and to get accurate details about the functions
> being covered. This is an unfunded task.
> 
> The work has resulted in a close examination of inlined code in RTEMS and what I
> saw alarmed me so I have added a report to the rtems-exeinfo tool in rtems-tools
> (the change is to be posted for review once I get the coverage tests running).
> 
> A summary report for hello.exe on RTEMS 5 for SPARC is:
> 
> inlined funcs   : 1412
>     total funcs : 1956
>  % inline funcs : 72%
>      total size : 174616
>     inline size : 81668
>   % inline size : 46%
> 
> This is a small application so it could be argued that skews the figures. A
> large C/C++ application built with -O2 running on RTEMS 4.11 ARM reports the
> inline usage as:
> 
> inlined funcs   : 10370
>     total funcs : 17700
>  % inline funcs : 58%
>      total size : 3066240
>     inline size : 1249514
>   % inline size : 40%
> 
> This does not seem right to me.
> 
> The report is new and there could be issues in the DWARF handling that feeds
> this report however I am posting this to start a discussion on the topic of
> inlining.
> 
> I attach the report for hello.exe. The `-i` option generates the inline report.
> 
> The first section is a summary showing the total number of functions in the
> executable that have machine code and are flagged as inline. The report lists
> the percentage of functions that are inlined and the percentage of machine code
> that is inlined. The values seem high to me.
> 
> The second table lists inline functions that are repeated sorted from the
> largest foot print to the smallest. The first column the total size of machine
> code in the executable and the second column the number of instances.
> 
> The third table is the list of inline functions sorted from largest machine code
> footprint to smallest. The second column are flags of which there is one. A `E`
> indicates the inline function is also external which means the compiler has
> created an external reference to this function, ie an address-of is being taken.
> The third column is the address in the executable so you can take a look with
> objdump at the machine code.
> 
> We need to ask some important question in relation to inlining. It is cheap to
> add and we all feel the code we add needs to be fast and needs to be inlined but
> does it really need to be inlined?
> 
> Some pieces of code do need to be inlined and the overhead is just that an
> overhead, for example in the large C/C++ application there is a low level
> volatile hardware write routing with close to 300 instances and a code size of
> 10K. This code needs to be inlined for performance reasons but should the size
> on average be 40 bytes, I doubt it.
> 
> Can we be more judicious with our use of the inline keyword?
> 
> Is the performance gain we really expect or is the actual overhead of a call
> frame not worth saving?
> 
> What are the real costs of inlining a piece of code? It adds size to the
> executable and depending on the code being inlined it complicates coverage
> analysis be adding extra branch points.
> 
> The metrics to determine what should be inlined is complicated and I do not
> think we have a suitable policy in place. I believe it is time we to create one.
> 
> The issue is not limited to our code, gcc, newlib and libstdc++ seem to have
> some code that should be looked at more closely. For example __udivmoddi4, and
> __sprint_r.
> 
> Chris
> 
> 

Hello Chris,

I just took a look at one of the first function in your list: __sprint_r

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=c4bf2dbe31da64462ecccec97c8e901e4ffadd44;hb=HEAD#l403

As far as I can see, there is no explicit inline key word for that
function. So in that case, the compiler decided that it would be a good
idea to inline that function.

I'm not sure whether I might just haven't seen it but is there a
possibility to distinguish between functions that have been inlined by
the compiler and ones that have been inlined due to the "inline" keyword
without looking at every definition?

Did you try compiling with size optimization? I would expect that the
compiler would inline far less functions and maybe even ignore some
"inline" keywords. As far as I know it's more of a hint to the compiler.

I would only worry about functions that are still inlined if size
optimization is selected. That's the case when I tell the compiler to
make the program as small as possible. In all other cases I want some
well balanced optimum between speed and size. Inlining small functions
is OK in that case if you ask me.

Best regards

Christian