Inlined code

[Chris Johns]

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