Re: adding COPTS to shrink kernel binary size

On Thu, 9 Feb 2023 at 14:05, Izumi Tsutsui <[email protected]> wrote:
>
> 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

This would not need to be an "everything or nothing" decision. Maybe adding
  -fno-unwind-tables -freorder-blocks-algorithm=simple
for all m68k ports and vax, and then look to potentially refine later
with -fno-reorder-blocks -and/or -Os. After all, it would probably be
best to compare the speed difference of -Os against
"-fno-unwind-tables -freorder-blocks-algorithm=simple" (given the
latter is approximately "free" regained memory).

There are likely other ports which would benefit from the same changes
- hpc{mips,arm,sh3},dreamcast,acorn32,epoc32 and other particularly
memory constrained platforms, but I would very much support m68k and
vax being adjusted first.

David