This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [GCC 3.0] Bad regression, binary size
On Mon, Jul 09, 2001 at 09:09:08AM -0700, Linus Torvalds wrote:
>
> On Mon, 9 Jul 2001, Marc Espie wrote:
> >
> > In article <200107082128.f68LS4x08156@penguin.transmeta.com> you write:
> > >gcc-3.0 already gets complaints for generating slower and more bloated
> > >code than previous gcc releases. That should tell people something.
> >
> > Try not to jumble things together, please. The ix86 alignment properties
> > is nothing new at all.
>
> Hmm.. It was reported as the potential reason for the bigger OpenBSD
> kernel.
No, you read this a bit too quick. Someone suggested to use
-mpreferred-stack-boundary to get the size back down, which actually does
work, but still does not give me any idea why my kernel is suddenly bigger.
The actual object sizes is +10K,
The resulting kernel is +60K,
compressed size difference is even larger.
As far as I know, my linker gets confused and no longer merges stuff it
used to, which I now wish to find.
Now, the rationale for keeping -mpreferred-stack-boundary `high' by default
is that mixed code (`normal' code + floating point code) does need that
boundary by default, so if you turn that off, say in library code, then
all floating point code loses (because it's somewhat inefficient to regain
proper boundary, and the compiler does not really know when to emit that
code, e.g., where is the boundary between floating point code and
non-floating point code, since this is global stuff that isn't even
`fixed').
Kernels are special beasts, since they are completely isolated from
userland, and hence their stack boundary issues are very well isolated.
All this is even documented in the gcc documentation (e.g.,
preferred-stack-boundary is marked as a beneficial tweak for embedded
systems).
I can hardly fault the gcc team on preferred-stack-boundary...