This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: linux 2.1.117 built with egcs-1.1 19980823
- To: law at cygnus dot com, Andi Kleen <ak at muc dot de>
- Subject: Re: linux 2.1.117 built with egcs-1.1 19980823
- From: Andi Kleen <ak at muc dot de>
- Date: Mon, 24 Aug 1998 20:31:33 +0200
- Cc: egcs at cygnus dot com
- References: <k21zq6ikf4.fsf@zero.aec.at> <12461.903972211@hurl.cygnus.com>
On Mon, Aug 24, 1998 at 05:23:31PM +0200, Jeffrey A Law wrote:
>
> In message <k21zq6ikf4.fsf@zero.aec.at>you write:
> > >> 2.7.2.3 options: -O2 -m486 -fno-strength-reduce -malign-loops=2
> > >> -malign-functions=2 -malign-jumps=2 -fomit-frame-pointer
> > >> egcs options: -O2 -mpentiumpro -fno-strength-reduce -fomit-frame-poin
> > > Could be alignment related. egcs aligns code according to intel's
> > > recommendations, which may (or may not) account for some increase.
> >
> > Alignment explains about 4k (tested by using the same -malign-* options
> > like with 2.7.2)
> You might try -fno-gcse to see if that accounts for some of the increase in
> space. Our global cse code will tend to make stuff bigger in attempt
> to make it faster.
I noticed also that it seems to use more stack space than 2.7.2.3; I diffed
a few functions and egcs1.1 often generated a bigger stack frame. Other
than that I didn't see anything that could explain the big growth: it
generated slightly different code for some things, but nothing that should
be that much bigger.
Is it possible that egcs1.1 inlines more aggressively than 2.7.2.3?
-fno-gcse seems to buy another 4k (to the old alignments), but the text
segment of the egcs1.1 compiled kernel is still about 22k bigger than
that of a 2.7.2.3 compiled one (data segment is about 1k bigger).
I'm not sure why the data segment grows, did egcs change anything that
could explain that? (exceptions are turned off of course)
Another thing that I noted (2.7.2.3 had the same problem, but it had less
impact because the code needed less registers):
Linux TCP often does stuff like:
static void tcp_fast_retrans(struct sock *sk, u32 ack, int not_dup)
{
struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);
/* Lots of usage of both sk and tp */
}
It seems the cse/gcse passes fail to notice that tp is just sk+offset (which
could be folded for most structure accesses). In the 2.7.2.3 compiled code
both sk and tp took a global register, but in the egcs1.1+gcse code it seems
to use more registers and tp gets a slat stock and is bounced between the
stack and some registers all the time - not good in a time critical path :(
-Andi