From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier To: Richard Henderson , Marc.Espie@liafa.jussieu.fr, gcc@gcc.gnu.org Subject: Re: [GCC 3.0] Bad regression, binary size Date: Sat, 07 Jul 2001 14:41:00 -0000 Message-id: <20010707234148.C10109@pcep-jamie.cern.ch> References: <20010705163930.A29149@schutzenberger.liafa.jussieu.fr> <20010707130928.A2761@redhat.com> X-SW-Source: 2001-07/msg00538.html Richard Henderson wrote: > > -rwxr-xr-x 1 espie wheel 3994332 Jul 5 16:08 bsd > > > > 3.0: > > -rwxr-xr-x 1 espie wheel 4068067 Jul 5 16:35 bsd > > > > Exact same source. Both are using -O2 -Os to compile. > > Also try -mpreferred-stack-boundary=2. The default is 16 byte > alignment, which your kernel almost certainly doesn't need, and > there is extra code to maintain that alignment. By the way, is this 16 byte stack alignment going to be a permanent feature? As far as I can tell, it is not necessary to 16-byte align all functions just to help the performance of a few. Instead, functions which pass aligned arguments or use aligned locals, and which don't receive any aligned argument, could use "and" to align the stack themselves. It is necessary to record the original stack pointer, but that is easy enough. (The one case where this rule isn't perfect is variadic functions, but alignment-related performance is not really an issue for those). It seems to me this would improve performance, code density, and reduce stack usage of functions which do not need the extra alignment, while at the same time allow functions which do benefit from stack alignment to perform as well as they do now. This would also have the benefit that if a larger alignment is required for some object, for example some structures like to be cache-line aligned, then that can be accomodated too. cheers, -- Jamie