On 05/08/2018 19:39, Christian Mauderer wrote: > 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.
Thanks and yes. At this point in time I cannot tell what is happening and I am not sure the tool is reporting accurate data, I need to investigate. > 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? I am not sure. The DWARF data is complex and detailed and I view this initial step into the area of using DWARF to perform static analysis of RTEMS executables as green. DWARF does provide declaration attributes. I need to review the DWARF data and standard to determine if we can tell what is declared inline and what has been inlined. I think it would be good to know. > 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. Not yet. A complete tool build with those options is a lot of effort and I am still not comfortable the report is accurate. I think this is something that should be done at some point. I think it would create an interesting data point. > I would only worry about functions that are still inlined if size > optimization is selected. I think we need to review the functions we currently have tagged as inline. I think the only way we can do this is with real data. > 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. How do you define this, ie what is the inline policy we use? How do you audit this? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
