This is the mail archive of the gcc-bugs@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: stack manipulations in gcc-2.95.2


In the attached zip file you will find all the code generated by gcc.
The command line for the compiler is:
gcc -g -O2 -DULONG_IS_32BIT -DULONG_NOT_DEFINED -S -c alglin2.c
The included file alglin2.s contains the code as generated by gcc -O2 -g
under windows NT mingw32. Using the stabs info you can see immediately
what assembler code corresponds to what source line of alglin2.c.

Note that there is NO FP code in that module, and that sequences of FOUR
or FIVE successive additions to the esp register are generated that will
always provoke a stall!!!!!!

Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France

On Wed, 12 Jan 2000, Jeffrey A Law wrote:

> 
>   In message <m1284xO-000Y2gC@jacob.remcomp.fr>you write:
>   > Hi
>   > 
>   > I have noticed that very often gcc generates code like:
>   > 	addl 	$-8,%esp
>   > 	pushl	arg1
>   > 	pushl	arg2
>   > 	call	something
>   > 	...
>   > 	addl	32,%esp
>   > instead of the sequence used in most compilers:
>   > 	pushl	arg1
>   > 	pushl	arg2
>   > 	call	something
>   > 	addl	$8,%esp
>   > that is 3 bytes shorter!
> Generally the compiler does.  However, there are some circumstances where
> it can't (due to phase ordering issues).
> 
> 
>   > To make things worst, there are often sequences like:
>   >         addl $32,%esp
>   >         addl $-4,%esp
>   >         addl $-8,%esp
>   > instead of combining this into
>   > 	addl $20,%esp
>   > saving 6 bytes.
> I'd like to see sample code for this one.  Again, due to phase ordering
> issues it is possible to get a pair of stack pointer adjustments back
> to back, but they're rare.
> 
> 
>   > This is not a bad idea, but I am very skeptical if the code bloat that
>   > this produces doesn't largely offset any possible gains for cache
>   >  alignment.
> Getting stack alignment right can mean a factor of 2 or more for FP intensive
> code on modern ia32 machines as measured by standard benchmarks like Spec.
> 
> jeff
> 
> 
> 
> 

gccbug.zip


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