Re: egcs produces bloated code by default
On Sun, Oct 25, 1998 at 09:41:55PM -0700, Jason Gunthorpe wrote:
> > There's a tremendous size difference between optimized and unoptimized
> > versions (opt->noopt is 63k->109k). This doesn't bother me much, since
> > non-optimized code isn't supposed to be all that small or fast. Fine.
>
> Erm, that's misleading, you are calling '-fno-exceptions' an optimization,
> it isn't an optimization it's disabling a feature. The size difference
> from .neopt to .opt is 3k which is exactly what you'd expect. The
> difference from .mopt -> .noopt is 6k which is pretty expected.
Oops, you're right, that is rather bad terminology. All the names ended in
"opt" so I could "ls *opt" and get a useful list :)
However, when I disable a feature I'm not using so I can cut the size of my
executable by 40% without any change in functionality, I call that an
optimization.
> > Is this really acceptable? When the 2.2 kernel is released, Debian will
> > probably switch to using egcs for the C compiler, as well as C++. That
> > means, unless I miss my guess, that almost all of Debian will increase
> > in size by 40% unless we add these compile options. I don't think that
> > should be necessary.
>
> No, exception handling is a C++ only feature it will have no effect on C
> programs whatsoever [huge egcs bug otherwise]. We have already taken the
> size penatly for exception handling when we switched to eg++.
My understanding (which may be pathetic) was that _all_ functions in the
program must be compiled with exception-handling enabled if we want it to
work correctly. I thought that would include libc (which is C only) as well
as applications.
I guess I was wrong.
Have fun,
Avery
Reply to: