Re: adding COPTS to shrink kernel binary size

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

uwe@ wrote:

> On Sat, Feb 04, 2023 at 08:12:43 -0800, Jason Thorpe wrote:
> > Saving every precious byte of RAM on a VAX is probably a worthy goal.
> 
> May be use -Os plus selected -f options?  Older gcc versions used to
> be very zealous about -falign-* that are turned on with -O2

rillig@ wrote:

> Am 04.02.2023 um 17:12 schrieb Jason Thorpe:
> > Saving every precious byte of RAM on a VAX is probably a worthy goal.
> 
> What about -Os? For usr.bin/make, this results in a 14% reduction of
> binary size on x86_64, maybe it's similar for the kernels on vax.

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

As gcc man page says, newer gcc has "-freorder-blocks-algorithm" option,
but in gcc 4.x days it looks there was no option and "stc"
(software trace cache) was the only option.

m68k was switched to using "-O2 -fno-reorder-blocks" but I guess
"-freorder-blocks-algorithm=simple" could be another compromise for vax,
because newer VAXen have much larger cache than m68k and reordering
might be worth on them.

Thanks,
---
Izumi Tsutsui