This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: linux 2.1.117 built with egcs-1.1 19980823


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]