Re: adding COPTS to shrink kernel binary size

Den 2023-02-09 kl. 15:05, skrev Izumi Tsutsui:
> 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?
I would assume that -Os helps Vax both on real hardware and using Simh.
I cannot think of anything that would affect performance significantly, 
even though vax function calls are somewhat expensive.

-- R