cvs commit: src/sys/dev/lnc if_lnc.c

[Bruce Evans]

On Tue, 22 Jul 2003, Poul-Henning Kamp wrote:

> In message <20030722104524.GA80471 at survey.codeburst.net>, Paul Richards writes:
> >On Tue, Jul 22, 2003 at 02:22:00AM -0700, Poul-Henning Kamp wrote:
> >> phk         2003/07/22 02:22:00 PDT
> >>
> >>   FreeBSD src repository
> >>
> >>   Modified files:
> >>     sys/dev/lnc          if_lnc.c
> >>   Log:
> >>   Don't inline ridiculously very large functions.
> >>
> >>   Compared to the contents of these functions, an extra function call
> >>   is nano-peanuts.
> >
> >Both of those functions were called from just one place, inside the
> >interrupt handler. Is there any reason to not inline them?
>
> Yes, we need to get -Werror on the kernel again, and GCC whines about
> ridiculously large functions.

I think you mean "gcc emits the requested diagnostic about functions that
it doesn't inline, whether they are large or small".

Just turn off -Winline to not request this diagnostic.

> Inline should not be used unless it has a measurable impact on
> performance.

Several places, including if_lnc.c, used __inline to get cleaner code
at no cost in performance.  Removing __inline adds a tiny cost.

I build RELENG_3, RELENG_4, -current, and my version of old version of
-current all with the -current gcc.  I only turned off -Winline for
my version of -current since -Werror isn't on in the others.  The number
of inlining failures for a kernel with similar features but unsimilar
bloat is:
RELENG_3: 19 (15 for writertc in clock.c)
RELENG_4: 39 (18 for writertc in clock.c)
-current: 3167 (the leaf inlines haven't changed that much, but the bloat
                around them has)
-my-not-very-current: ? (see no evil)

Bruce