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: Andi Kleen <ak at muc dot de>
- Subject: Re: linux 2.1.117 built with egcs-1.1 19980823
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 24 Aug 1998 21:29:55 -0600
- cc: egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <19980824203133.A5883@kali.lrz-muenchen.de>you write:
> 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.
That could be the case if we're generating more spills. Some of the
loop improvements can increase register pressure, which might in turn
lead to more spills and more stack usage.
> I'm not sure why the data segment grows, did egcs change anything that
> could explain that? (exceptions are turned off of course)
Very bizarre. I'm not aware of anything which would have this behavior.
> 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 :(
Can you give a more complete example? This would normally be the
job of local cse and combine. global cse won't make this kind of change.
jeff