Re: adding COPTS to shrink kernel binary size

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

uwe@ wrote:

> > One concern of using -Os is inline functions.
> > 
> > In netbsd-6 days, m68k ports also used -Os but I noticed some
> > applications (especially mlterm-fb on slow luna68k framebuffers)
> > were much slower (~30%) with -Os because inline functions were used
> > as macro in loops for screen scroll rendering copy ops:
> >  https://mail-index.netbsd.org/port-m68k/2014/06/22/msg000488.html
> 
> If they are intended to be always inlined, they should be declared
> with the always_inline attribute.  -Os doesn't turn off inlining in
> general, but since inlining usually does increase code size you need
> to tell the compiler.  (E.g. sh3 kernel cache code does this b/c cache
> must be accessed by code in uncached P2, so macro-like inline
> functions must be inlined, or they will be called via their normal
> addresses in the cached space.)

I know the sh3 case.  If the functions need essencially to be inlined,
"always_inline" is mandatory.

On the other hand, if a port has an explicit upper size limit
(like sun2 and sun3 due to bootloaders) -Os is the only choise.

In vax case, not all VAXen have size restrictions, especially
simh users. I'm afraid such users (who are building packages etc.)
rather want proper performance than smaller kernels, so I just
thought -freorder-blocks-agolithm=simple could be a compromise.
(-fno-unwind-functions may be harmless though)

Maybe only the port maintainer can make a decision?

---
Izumi Tsutsui