On 06/08/2018 15:30, Sebastian Huber wrote: > Hello Chris, > > this looks like a very interesting tool. The justification for an inline > function must be done case by case.
I agree. I think a workable pattern will appear and my hope is this tool can be taught what is OK and what is not. I hope Joel discusses coverage analysis. This is another factor we need to consider. > > On 05/08/18 04:00, Chris Johns wrote: >> inlined repeats : >> 19172 16 __sprint_r > > This is a small function. GCC decided that it is worth inlining. With -O2 GCC > doesn't care much about code size. Please have a look at the updated report. Things have changed with better accounting of the size. I have dumped all the data here: https://ftp.rtems.org/pub/rtems/people/chrisj/coverage/inlines/ It has the inlined report, the DWARF dump and the assembler. I am not sure about the inline function addresses shown. I think I need to see what is happening here a little more. For example for __sprint_r DWARF range data has a class of 'sec_offset' which means I may need to get the section the code lives in so the section offsets mean something. I think the current addresses are wrong. > >> 1948 4 __udivmoddi4 > > We should figure out what is going on here with this __udivmoddi4. > Yeap. > I think uninteresting functions are the ones with inlined / repeats / opcode > size <= 4 and repeats == 1. I think this may depend on the machine work size. That data is present in the DWARF CU info. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel