Inlined code

[Joel Sherrill]

On Thu, Aug 9, 2018, 11:50 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> ----- Am 6. Aug 2018 um 21:14 schrieb joel joel at rtems.org:
> [...]
> > We looked at a lot of generated assembly. Sometimes we would see
> > large methods being inlined multiple times. This would increase the
> overall
> > size of an RTEMS application. But size is not the only impact of
> inlining.
> > If an inlined method has one or more if's in it, then the branch paths
> > it includes are introduced EVERYWHERE it is inlined. When we
> > had _Thread_Dispatch_enable, I recall it was used > 100 times and
> > includes a branch in it. There was a build option to not inline this
> > routine to avoid needing to add over 100 test cases.
> [...]
>
> I had a look at the _Thread_Dispatch_enable() code and was a bit surprised
> that GCC generates a stack frame in this function.  This turned out as a
> bug in the function. Do you find it? I will fix it tomorrow.
>

Chris and I were just counting instructions and branch paths. But I do
recall seeing ret and restore. That's a hint it is really too big to inline.

Perhaps the check for yes/no to dispatch should be inlined and the rest in
a method. This is how it was historically.

  If (--dispatch disable level)
    Call thread dispatch

But this only avoided the call on non-interrupt cases so not inlining at
all really wasn't a hit. I suspect the same now. Nearly all the time it
calls a subroutine anyway and 3K of code is added uselessly.

Look at it holistically. What is executed when it is a different is not
inlined?


> Before we start to turn inline functions into non-inline functions we
> should create a benchmark program (or more). We should look at the overall
> code size changes and the local code changes.
>

We were relying on checking size and our benchmarks before.

One metric was the size of the code we were analysing for coverage. That's
directly in the coverage reports.

Another metric when a lot of branch paths have been inlined is the number
of uncovered ranges. When you investigate and realize they are from an
inlineethod used in N places, it is clearly something to.look at.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180809/b09c271c/attachment-0002.html>