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