Re: ridiculous amounts of padding

[Marc Espie <espie@quatramaran.ens.fr>]

In article < 199901140044.TAA11843@jwlab.FEITH.COM > you write:

>It's certainly worth considering having this type of thing controlled by
>-Os.  Many of the alignments done for performance result in an increase
>in size which may be undesirable in some situations.  BTW, in all fairness
>I would be surprised if the 27.5% space increase is representative of the
>total size change that the final executable experienced due to extra
>alignment.

In case you should care, I have a system on which such small differences
make a difference.

OpenBSD is considering switching to egcs 1.1.1 (or a later release :) )
from gcc 2.8.1.

The main stumbling block is that code output by egcs under -O2 on 
i386-aout is *larger* than code output by gcc 2.8.1.

Something like 30K for a 2MB kernel, which is somewhat large.

Part of it can be accounted for by stricter alignment issues (but not much
mind you).

Part of it can be traced to an embarrassing behavior of egcs, which tends
to leave stuff on the stack longer instead of using registers... same number
of cycles, larger code.

... plus some differing passes, since egcs has changed. The gcse seems to be
the main offender... -Os improved the code size, -fno-gcse improved it some
more, relaxing constant string alignment improved almost *nothing*.

If someone would be interested in helping me tracking down code differences,
I am very interested...

I already asked about this specific problem a few weeks ago, I've got next
to no feedback until now.

This is a real problem: for performance freaks that care only about C
code quality, it seems that at least on i386, egcs is a bad idea: code is
larger, and looking at assembler fragments does not indicate a trade-off
between code size and efficiency.

It may well be that I'm mistaken, or that I'm missing something obvious.
But until someone corrects me (or I find a solution myself), OpenBSD will
have to stay with gcc 2.8.1 (as much as I would like a change, personally).