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

[David Schultz]

On Tue, Jul 22, 2003, Poul-Henning Kamp wrote:
> In message <20030722235600.X8165 at gamplex.bde.org>, Bruce Evans writes:
> 
> >Several places, including if_lnc.c, used __inline to get cleaner code
> >at no cost in performance.  Removing __inline adds a tiny cost.
> 
> You know, I would have agreed with you on that, if we were talking
> about a CPU with no caches, no branch-prediction and no prefetching.
> 
> For modern CPUs however it would be hard to prove the above statement
> true or false with any sort of measurement setup we have access to,
> and it would be even harder if not downright impossible to prove
> that the result was generally applicable to a majority of the current
> hardware on the market.

gcc is a bad model to follow here.  It disables inlining to
salvage compile time where its register allocation algorithms
don't scale.  And since it's disabling the inlining all by itself,
there's no need to bend over backwards to appease it.

The cost of not inlining is insignificant on i386, but it can be
very significant on architectures with sliding register windows,
such as sparc64.  On sparc64, a trap is taken every time the
procedure call depth changes by more than 6.  An inlining can mean
the difference between super-efficient procedure calls and having
to slide the register window back and forth at great penalty.
This problem wouldn't be so bad if we had a production-quality
sparc64 compiler that did aggressive tail-call elimination, but for
the moment we're stuck with gcc.

Another argument for inlining is that there are some very large
functions where inlining the function allows the compiler to
optimize away most of it after constant propagation.  The savings
can be substantial if you can optimize a test in an inner loop.
For instance, vm_object_backing_scan() takes a mode flag that is a
compile-time constant.  (In this particular case, however, there
may be a significant code size difference that we don't want to
pay for, since the function is used more than once.)

> I would _really_ love to nail up a policy note which says that "inline"
> should only be used if it is possible to show an effect, either because
> inlining reduces the code size (in this particular case less bytes to
> execute is generally an indication of better performance) or by
> showing actual performance improvements from the inlining.

There is reason for concern about cases where inline really is
misused, either because it massively increases code size or
because it is unimportant to performance and detracts from
debuggability.  But I would not like to see a policy that shifts
the burden of proof onto authors of new code.[1]  A policy about
gratuitous sweeps through other people's code, on the other
hand...


[1] In practice, just about any contentious case of inlining is
    going to be a wash anyway, and neither side of the argument
    is entirely without merit.  I'm mostly opposed to a new policy
    on the grounds that it's just another stupid rule, complete
    with technicolor bikesheds, to throw in the faces of people
    trying to do something useful.