This is the mail archive of the
mailing list for the GCC project.
Re: The bloat sweepstakes...
On Wed, Oct 10, 2001 at 04:24:03PM +1000, Fergus Henderson wrote:
> On 07-Oct-2001, Zack Weinberg <email@example.com> wrote:
> > Largely for amusement, here's some statistics on the sizes of the
> > compiler binaries. All figures are in kilobytes, for the final stage
> > of an i386 native bootstrap. First, the back end:
> > text rodata data bss total file
> > 2360.3 457.2 17.2 494.5 3329.3 libbackend.a
> Note that the rodata and bss sizes are both problematic for the Mercury
> front-end. The reason is that the Mercury front-end uses the Boehm
> conservative collector, which scans the bss section and
> (on most systems) the rodata section. (There's actually no need for
> the conservative collector to scan the rodata section, since that can't
> contain pointers to the heap, but unfortunately it's hard to tell where
> the rodata section starts and ends.)
That seems strange to me: it does scan rodata and it doesn't scan
text? On most systems I am familar with, the boundary between
(text+rodata) and (data+bss) is obvious, but the boundary between text
and rodata is not. I very much hope it doesn't scan rodata, because I
have Cunning Plans to reduce the text size considerably at the expense
of a somewhat larger rodata. Note that much of rodata is strings.
These are the largest single items in cc1's bss segment (sizes in KB):
None of these contain any pointers. Perhaps what is needed is some
sort of annotation visible to the Boehm collector, that certain data
or bss items do not contain pointers.
I think costs never get higher than 10 or so; we could cut the size of
the cost arrays by a factor of four by using unsigned char instead of
int. Or am I mistaken about this?