Re: adding COPTS to shrink kernel binary size

Izumi Tsutsui <[email protected]>
Newsgroups gmane.os.netbsd.ports.vax,gmane.os.netbsd.devel.toolchain
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.